I am building an HTTP API in java that uses AWS cognito, and developer authenticated identities to provide tokens to secure the API. I have configured the login system to issue a cognito token when a user logs in and the cognito identity pool contains each user and a developer identity associated with my backend, but I am having a very difficult time finding a straightforward way to retrieve a users specific developer identifier from the cognito token. I have attempted to use the AssumeRoleWithWebIdentityResult API call, but have been unable to find documentation about it for determining the developer identifier, only examples for obtaining temporary AWS credentials.
Once you have temporary AWS credentials, when you call the backend, you can access to the cognito identifier of the caller in the context. Then you can retrieve the developer identifier using lookupDeveloperIdentity on the server side.
Check theses pages to retrieve the context data if you are using API gateway or Lambda
In the token returned by GetOpenIdTokenForDeveloperIdentity, the unique identifier that you gave the user is in the "amr" field. So you will need to crack open the token to get it.
EDIT: As Alexis N-o pointed out, you can look up the developer identity with the Cognito Identity ID:
http://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_LookupDeveloperIdentity.html
Related
I would like to integrate PayPal signin into an android app so to authenticate the client to the Firebase Database. I've managed to create a custom funtion on the node.js server that creates tokens from the provided uid, in order to use "signin withcustomtoken" function in the client application. Should I send the uid to the nodejs server through https in order to get the token? Is there a better way?
Don't create an HTTP endpoint that accepts a uid and returns a custom token. This is a huge security vulnerability as any attacker would be able to impersonate any user knowing their uid.
What you need to do is the following:
Implement a paypal OAuth code flow. You can use third party libraries for that.
When you get the paypal OAuth authorization code, you send it to your backend, you use the paypal client ID and secret to exchange for a paypal refresh token and access token. You can then get the user info associated with that paypal user including their paypal uid. You would then mint a Firebase custom token using the Firebase Admin SDKs and return it to the client.
On the client you would signInWithCustomToken to complete sign in with that custom token.
In this case you are exposing an HTTP endpoint that takes an authorization code and returns a Firebase custom token.
This is the basic idea (details excluded). Of course you still have to ensure the flow starts and ends on the same device by passing some state and then check that you get it back in the end. You also have to ensure the auth code is returned to the correct app using something like app links, etc. Firebase Dynamic Links can be helpful there.
I think it will be hard question. Anyone had dealt with cognito and Twitter. Last do not support OpenID. So have any idea, how can synchronize these two things.
Cognito documentation said only: Using Cognito, developers can store information such as user ... that are not natively supported by Cognito, such as Twitter or LinkedIn™
In order to use twitter, you would need to implement it as a developer authenticated identity provider http://mobile.awsblog.com/post/Tx1YVAQ4NZKBWF5/Amazon-Cognito-Announcing-Developer-Authenticated-Identities
The basic flow would be:
Implement an identity provider that prompts the user to log in with twitter on the device. Using the token twitter returns, call the authentication backend you create to validate the token using the twitter api.
After validation, call GetOpenIdTokenForDeveloperIdentity from your authentication backend using developer credentials. Return the identity id and OpenID Connect token back to the device.
The Cognito credentials provider will then exchange the OpenID Connect token for aws credentials tied to that twitter identity.
Full details about the identity provider interface and flow are available in the dev guide:
iOS or Android
If you don't want to manage the communication with twitter yourself, you may want to consider integration with an another service such as Auth0, which itself integrates with Cognito via OpenId Connect tokens and no back end.
See this blog post and this sample app for an iOS example.
Update 2015-04-30: Amazon Cognito has been updated to natively support Twitter and Digits. Read more on the AWS Mobile blog as well as the Amazon Cognito developer guide.
I'm having a hard time wrapping my head around how to authenticate a user in my REST service. I plan to use Google Sign-in (on Android, namely). I can't quite figure out how to authenticate users on my server. I do not want to have any authorizations (other than validating the identity of the user), all I want to do is when I receive a request, validate that the user is who he (or she) says he is.
My understanding is that the user will login, get some sort of token from Google, then send that token along his request to my server which I will use to validate his identity. However, from what I read, the user will encode their requests in a JWT (json web token), which I will then use to validate their identity without ever talking to the Google server directly. Did I understand properly?
On Google's documentation, it says
If you do not require offline access, you can retrieve the access token and send it to your server over a secure connection. You can obtain the access token directly using GoogleAuthUtil.getToken() by specifying the scopes without your server's OAuth 2.0 client ID.
But it does not say what the server should do with the token.
You have an android app which enables user to log in via Google+ Sign-In, and then this Android app will call your REST API. What you want is how your service authenticates this request. This Android client will send request to your service with token, and you need to validate this token for authentication. Is my understanding right?
If so, you need to validate the token sent to your service. The reference you mentioned is for Google API calls, in your case; it's your own service API call. For the Android side, just follow the reference, in your service side you can use TokenInfo validation to authenticate users.
I managed to implement the auth function described by google using a clientid.
So when visiting the html page, one gets asked to authenticate with a google account.
Question: As it is now, everyone can use the site, as long as he/she has a Google account to authenticate with. How do i restrict the usage to a certain group of users? Do i need to manage a list of unique user ids provided by the User object? Or is there already something prebuild, that i can make use of?
I think the safest would be to keep a list of Ids. What are the basis that you expect google or anyone else to know what kind of users you want to allow?
Even if its only geographic there are times when people might be using proxies or using yor site from a remote location.
The site you linked to also says so much :
Specifying Authorized Clients in the API Backend
You must specify which clients are allowed to access the API backend
by means of a whitelist of client IDs. A client ID is generated by the
Google API console from a client secret, such as the SHA1 fingerprint
of a key used to secure an Android app, or from the Bundle ID/Apple
Store ID pair for an iOS app, as described in Creating OAuth 2.0
Client IDs. At runtime, a client app is granted the authorization
token it needs to send requests to the API backend if its client
secret matches one contained in a client ID within the API backend's
client ID whitelist.
Also its only common authentication (who is it), authorization (what they can do on your site) comes from you.
I am developing a Java application that needs to access personal account Google Data of a user. The development is currently in netbeans on my localhost. I am implementing 3-legged OAuth. And while sending Grant request, it sends me Unauthorized Request Token and then redirects to Callback URL.
While trying to access Access Token, it gives me Error "Error Getting HTTP Response". Now, as per it given in Google Documentation, it is given that "If the application is not registered, Google uses the oauth_callback URL, if set; if it is not set, Google uses the string "anonymous"." Does it mean that I must register my application on Google Apps Engine before granting authorization & accessing request ? Please Help.
For reference : OAuth for Web Applications, OAuth in the Google Data Protocol Client Libraries
Based on your question, it's probably not the registration piece that's causing you trouble. It sounds like you just haven't implemented OAuth correctly — not that doing so is easy. The OAuth process is roughly as follows:
Get a request token. You must pass in a bunch of stuff that declares what kind of stuff you want access to and where you want Google to send the user when they're done granting you access to that data. This is where you pass in your consumer key, which you get by registering. The consumer key will be the string anonymous if you are developing an installed application (i.e., mobile app, desktop app, etc). This is a work-around; the alternative would be to embed your client secret or RSA private key within the application itself, which is a very, very bad idea. If you use 'anonymous', you should absolutely be setting the xoauth_displayname parameter. (Actually, everyone should set this parameter, but it's especially important if you're using anonymous.)
Once you have a request token, you then redirect the user to the special authorization endpoint, passing along the request token key in the query string. Assuming the user grants access, Google will redirect the user back to the callback URL that you associated with your request token. The request token is now authorized, but it can't be used directly just yet.
Once the request token is authorized, you can exchange it for an access token key/secret pair. The access token key/secret can then be used to sign requests for protected resources, such as the private data in the API you're trying to access.
For web applications, registering is almost always a good idea. It makes it much easier for users to manage their access tokens and revoke them if your application misbehaves or if they don't want you to have access anymore. If you don't register, your application will probably show up as a fairly scary-looking 'anonymous' in that list. It's really only installed applications that you wouldn't want to register for. You probably also want to register for an API key. An API key will dramatically increase your rate limit and it will also allow Google to get in touch with you if your application starts to malfunction.
I'd link to the OAuth docs, but you've already found them. Hope my explanation helps!
If you're developing on your local machine, you'll continue to get the same result as above.
For more interesting tests, then yes, you'll have to register your app and push it to the app engine.
Google will check if the domainname of the return-url is registered. You could also modify your dns/host-file to point the domain-name you're using to localhost.