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.
Related
I have my web application. Now i want to integrate salesforce into my web app so that i can push data from my app to any salesforce org after the authentication(OAuth).
I found 2 ways:
1. Connected Apps
2. via wsdl generation file and use
I created a connected app from my developer account and i authenticated using consumer key, cusumer secret key(from my connected app) and username of user and secret token of the user account.
I tried with another free trail account, It's validating and fetching the details and post data also working.
My question is, shall i deploy my connected app into app exchange, then only i caan use REST APIs ?
generating wsdl and coding around is the better option than the above ?
Is there a option, only one time authentication enough for any number of sessions and use the REST APIs?
Please suggest me a best way to proceed.
You're mixing up a couple of independent issues here.
If you're going to authenticate via OAuth, you must have a Connected App.
A SOAP API login() call requires you to store a username and password, which is undesirable.
There is no way to "permanently" authenticate, i.e., to get a session id that never expires. Your app must always be ready to get a new access token via the OAuth refresh token it obtains and stores (via, for example, the Web Server OAuth flow), or to reauthenticate via JWT flow.
Connected Apps are global metadata in most cases. You don't need to deploy a Connected App into a target org in order to authenticate using its Client Id and Secret into that org. The only exception I'm aware of is if you want to use the JWT flow with a certificate and preauthorized Profiles and Permission Sets.
Based on what you've shared, I don't see any reason for the AppExchange to be involved.
How can one use Firebase Authentication to allow users to authenticate with a Google account via the C++ SDK (using it in Cocos2d-x).
I’m confused as to whether I would need to build a special Google auth GUI or if the SDK requires/contains a standardized GUI (or, in the case of Cocos2d-x, a Scene) that should be used.
Either way, I am unsure how to do it. Does anyone know how to proceed? The SDK example code shows how to authenticate via Email/Password but not via a Google Account.
Ok, so this is complicated, but not because of Firebase.
Basically, if you want to use a Federated Logon, such as Facebook, Google, Twitter, then you will need to use their UI SDK built for whichever platform you are using. When you successfully login with one of these services, you will construct a Credential with the token that is returned from one of these services.
After you login with this credential, the Firebase Auth service will associate any account data with this federated logon. If you were previously using an anonymous login, then the account should be upgraded. If you have already logged in with another credential (email, phone number, alternative federeated logon) then you will need to do some logic to check if you need to merge or switch.
Firebase Auth can outlive the Federated Token. For example, the Facebook Login token expires or is revoked, your Firebase Auth backend might remain signed in. Vice versa your Facebook token might not expire, but your Firebase Auth might have been signed out. You will need to manage these states.
Here's an example. We want to use Facebook Login as our federated logon provider. We link the Facebook Login SDK for our platform as described in the Facebook Developer docs.
When we want to ask for Facebook login credentials, we use the FBSDKLoginManager .loginwithReadPermissions() to launch the login flow. This typically consists of launching either the Facebook App to confirm permissions for your app or the website (make sure you implement deep links properly as described in the Facebook documentation).
Eventually, the login will succeed or fail.
If it succeeds, Facebook will hand you a token which you can grab from [FBSDKAccessToken currentAccessToken].tokenString. This is what you would send to firebase::auth::FacebookAuthProvider::GetCredential
All of this is ASync and done on separate threads. You should use a concurrent queue to funnel these events to your main thread.
It is possible to use your own server and signup form, in which case you would build your own UI in game and then make secure server calls to your backend. There's a flow for getting a text message to validate a user, not something I would do for a game.
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.
The application which I am building maps a user_id to multiple facebook accounts. I have access tokens for each of these mapped accounts and everything works nicely. There is a problem, though, when one of these access tokens expires but the user is logged in to Facebook as a different user than the one to whom the expired access token belongs.
I read all there is about obtaining a new access token for the currently logged in user but I found nothing about the case when the user whose access token expired is not logged in to Facebook.
I would appreciate your thoughts and possible solutions.
Users can't have multiple Facebook accounts, so that part of your question doesn't entirely make sense, but in general, if an access token expires you need the user to come back to your app and go through the Authentication flow again, which will give you a new access token for that user
I believe the only way to get an updated access token would be to go through the whole authentication process again from the initial login screen.
Depending on the technology with which you're building your application, the only way I can imagine you'd handle logging in to a Facebook account without logging out of an existing one is to set up parallel instances of web browsers, so long as they don't share things like cookies.
I'm building an app which doesn't rely on a login system (no database) that will save user's data on dropbox/google drive and others
So when an user open the app he "login" using the cloud service.
Since I'm not going to use any database I was wondering if it's secure to store user oauth token (not the app one) in cookies.
If anyone gets access to cookies he can get access to user data on my app ot it will need also app tokens?
It depends on what OAuth version is used and what OAuth flow is used. Generally the OAuth access tokens can be stored only if it can be secured, for example stored in the key chain on iPhone where only application/user granted the access can get it. Same applies to refresh token in OAuth2