I'm just trying to get a handle over this framework and I want to confirm that my approach is correct.
I can authenticate my own user using the method: getOpenIdTokenForDeveloperIdentity and supplying an IdentityPoolId and a Logins key-pair with my Developer provider name and a token which I provide.
Now, from what I understand, when the user logs into a second device, in order for Cognito to understand that this is the same user, I have to provide it with an IdentityId. However, I'm not sure of the best way to get the IdentityId programmatically so that it will match up with the initial login.
The only technique I can think of is to store the IdentityId in my own DB and provide my own method for retrieving it. Is this the best way? Or should I be working with this framework differently?
I'm still a beginner to AWS in general and I'm just trying to understand the best practices for this framework.
BTW, I'm implementing the Android SDK and the PHP SDK for my backend.
When you use getOpenIdTokenForDeveloperIdentity, it returns the identity id associated with the user identifier you provided. So if the user identifier you use is the users' username, when you call getOpenIdTokenForDeveloperIdentity with that same username from the second device, it will return the associated identity id. There is no need to store the identity id unless you want to, it is provided to you each time you call getOpenIdTokenForDeveloperIdentity.
This blog post may be of further help:
http://mobile.awsblog.com/post/Tx2FL1QAPDE0UAH/Understanding-Amazon-Cognito-Authentication-Part-2-Developer-Authenticated-Ident
When you use Cognito, your user first authenticates with an Identity Provider (such as facebook, google or other Oauth provider), and the token you get back from it is sent to Cognito and is the key to tying your users information together across logins on other devices.
You don't need to store this information in a database, unless you are writing you own custom identity provider and not using one of the public ones available.
Related
I'm still a learner, please forgive me if I ask a simple question. I have an application which contains its own users table where I store the email and password. When the user logs in I store the user's information (without the password) in session and privilege IDs (so that I can manage who gets to see each page after the login).
I integrated a Cognito login. How should the integration with the existing users table work? After a successful Cognito login I get a token back. Can someone write me how do I integrate the Cognito token with existing users table? Any thoughts are appreciated.
Cognito returns a JWT token which can be decoded via libraries like https://jwt.io/
The output will be somewhat like
For your use case use "cognito:username" to identify the user and store an event against it
We are developing a web application in AWS which stores its users in Cognito. As part of this, we are required to have an integration with an existing desktop application, where the administrator of a client can create a read-only user for the website for data sent from the desktop app.
Because of this read-only user requirement, there has to be a user associated with the authentication for each instance of the desktop app installation. This is no problem, as we are happy that all local users of the desktop application have their data logged to the same place in the web application. The tricky part is that we are not able to have the username and password as common knowledge for the end-users of the desktop app.
It has been suggested that we could use token-based access to allow the desktop app to access our API, but these are all time limited and we would not be able to have the user re-authenticate each day. However, another suggestion is to create our own "key" which contains the username and password of the Cognito user in such a way that the application will be able to use it, such as encrypting the username and password with the decryption key available to the desktop app so that it can authenticate as that user itself without the end users having access to the account details.
I would like to know if there is currently any best practice way of handling a requirement like this that is better than what we currently have available.
To summarise:
We have an AWS API with Cognito Authentication
We have a desktop application which needs to access the API
We cannot have users know the details of the account being used to access the API
We need a way to provide a key that will allow the desktop application to authenticate itself against the API in such a way that the token will not need to be refreshed over time
Thanks for any help.
Unfortunately this requirement:
"We need a way to provide a key that will allow the desktop application to authenticate itself against the API in such a way that the token will not need to be refreshed over time"
is not going to be possible with Cognito. Assuming you are using Cognito user pools, the id and access tokens obtained on authentication are only valid for 1 hour, then they have to be refreshed using the refresh token. The refresh token can be configured to be valid for a really long time (years even) so you could setup a flow where:
The app authenticates itself against Cognito once
Gets a refresh token that is valid for a really long time
Throws away the original encrypted username/password
Uses the refresh token to get a new id/access token every hour
You would have to store the refresh token on the client somewhere though. And probably have a support mechanism where this process could be restarted on the client in case the refresh token is lost.
If you are using Cognito user pools, you are going to have to do token refreshes. Same is true if you are using Cognito identity pools - the AWS credentials provided by the identity pool are only valid for 1 hour, then they have to be refreshed.
I'm currently exploring the AWS stack and am therefore building a simple web app. I plan on using:
S3 to host the static contents
DynamoDB to store user data
Lambda + API Gateway for backend logic
Cognito Federated Identities to authenticate users
I currently have a small tracer bullet application working that allows the user to authenticate with Google (through Cognito) and retrieve some data through a Lambda from DynamoDB. Now I want to extend it.
The next thing I want to do (and am failing to achieve) is to actually store the user name and e-mail of the authenticated user. Storing it shouldn't be a big problem, but retrieving it is. I know I initially got the data from Google because when I inspect the ID token (on JWT.io) I got from Google, I can clearly see my e-mail and name. This is the token I sent to AWS Cognito in exchange for a Cognito token.
I was expecting to be able to access this data again in my Lambda function, but I fail to figure out how actually. I understand Cognito performs a one way hash on the retrieved ID token, but I would expect some options to actually retrieve relevant user data from the token. After all, by authentication through Google (or any other IdP) a user already consented to sharing some personal data.
I feel I fail to see something obvious. Is there any feature in AWS that solves this? Is there a moment (not on the client side) where I can inspect the ID token and do some magic with it? Or should I solve this in some different way?
If the latter is the case: what would be the preferred way? I don't want users to tell me their personal data, because then I would also need some way to validate it.
I'm trying to implement OAuth 2.0 for my API. I'm using a third party library to act as the basic OAuth provider, django-oauth2-provider,
and Tastypie as the framework. Those details shouldn't matter too much. The OAuth 2.0 works -- when a user is created, an OAuth 2 client
that manages the user's secret_key and their id is created. A customer can then supply the user ID they get back from the user creation
endpoint along with their username and password to get an access token which allows them to use API endpoints.·
Where I run into issues is retrieving the client id (which must be passed into requests for the access token). Obviously when a user is first created
I can return the client_id with the HTTP response. After that, however, there will obviously be cases where the user doesn't have their client id·
stored locally (this is a traditional user/app setup, not something like Google APIs where your client id is always visible). I want to protect
GET requests to the customer resource with OAuth, but that means I can't query the API for a given user's client ID. And it seems like the whole point
of OAuth is defeated if I can always just pass in a username and password to retrieve my client id from some oauth endpoint. Am I thinking about this wrong?
Also, from reading the OAuth specs I'm under the impression that a client id and client secret are all that should be supplied for getting granted an access token. Yet the implementation I'm using defaults to forcing the user to supply a client id, client secret, username, and password. I've overridden the implementation to require only the client id and secret, but I want to make sure that was the right call and I'm not missing something.
Edit for flup's response:
I'm dealing with a Django API as the resource server, and a user of an iPhone app as the resource owner. The iPhone app is directly associated with the server -- in other words, there are no third parties involved here and no plans to involve them in the future; all software is ours. I would think that the password flow would be what I would need in that case. Indeed, that seems to be what django-oauth2-provider supplies by default. I'd like to stay somewhat in line with what they are doing to not have to completely reinvent the wheel.
The goal of oauth2 is to let the resource owner give a client a valet key which authorizes it to access certain resources on your server on his behalf.
If there are no third parties involved, there is no client to authorize and no need to use oauth2.
Instead, you could use the standard authentication mechanisms present in tastypie.
I am building a app/API that allows user to login with Facebook, Twitter or Google. I am wondering what are the best practices in allowing those user to use the same account to login to the API.
A couple Ideas that I have had is pass the auth token/cookie in a header to the API for every request and use that to authenticate on the backend.
Run my own OAuth setup and make the user authenticate once with the back end to get my OAuth token and use those from then on.
I am doing the same thing and my solution is to match the email addresses that you get from these respective APIs.
For Facebook, you need special permission from the end user to get the email address registered there. You do this by adding &scope=email to the first oauth request.
A disadvantage is that you need to get this permission from the end user and they may decline. Another disadvantage is that users need to use the same email addresses for Google, Facebook and Twitter.
An advantage is that user records are merged automatically, so users can directly access all their data if they logged in the first time through Google, and the second time through Facebook.
Another approach would be to manually merge their data by making them log in to Google when they are already logged in through Facebook. Then you can conclude that they are the same user, even when they use different email addresses for both. But this is a more tedious approach, as you still need to merge the app's user data from both accounts.
Your first solution is exactly the way I do it. As all my rest services are stateless, the access token goes in the header and is parsed by spring security authentication filters on every request. I use a grails sever with the spring-security-oauth plugin. We also run a website which allows for using session cookies for browser based access.