My context:
An AngularJS application using the Javascript Facebook SDK, and my distinct server (REST APIs).
Workflow:
User is logged in the client through the FB SDK using the method FB.login(callback).
This later gives a short-lived token that is then sent to the server in order to transform it to a long-lived token.
I'm interested in the mechanism of refreshing the long-lived token after 60 days.
So, reading the doc, we found this:
Even the long-lived access token will eventually expire. At any point,
you can generate a new long-lived token by sending the person back to
the login flow used by your web app - note that the person will not
actually need to login again, they have already authorized your app,
so they will immediately redirect back to your app from the login flow
with a refreshed token - how this appears to the person will vary
based on the type of login flow that you are using, for example if you
are using the JavaScript SDK, this will take place in the background,
if you are using a server-side flow, the browser will quickly redirect
to the Login Dialog and then automatically and immediately back to
your app again.
If I interpret it well, when user is ALREADY logged in through FB.login(callback), a simple redirect to the Angular Application's login flow would allow to get a new short-lived token.
I imagine that the FB.login is immediately run anew in this case, without user interaction, as written.
I want to test it simply, so what I've done is:
Logged in into the application through FB.login(callback).
Clicked on a dummy link making a simple redirect with: window.location.replace('/');
My application being a single page application, every URL should be considered as the authentication page.
But the FB.login isn't run in the background, as I expected from the doc.
What would be the reason?
Does it work only when the domain making the redirect is distinct from the client? (I just can't test this case right now)
Did I misinterpret the doc?
Related
I have an implementation of IdentityServer4 which connects with Azure AD for authentication (OIDC). In the callback method, using the IdentityServertools, I am generating the access_token and redirecting the user to SPA with the same. The SPA then stores the access_token into localstorage and uses it for authentication.
Normally, when my SPA app hits the token endpoint of the IdentityServer4, it gives access_token and refresh_token and then uses refresh_token to re-authenticate a returning user.
In this case of SSO with Azure AD, do I need to generate refresh_token manually? If yes, I can build on top of default implementation and that's not the problem (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
My real question is, is there a need of refresh_token here? Because refresh_tokens are stored in DB and never get's deleted and after sometime, these refresh_tokens table will swell (right now it already has 80k rows). The user is expected to click on a small tile inside SAP's Successfactor - that will open the signin/consent screen of Azure or will directly take the user to the main page where zhe will just answer a question and done. So it's hardly 2-3 mins business. So I can continue to generate access_tokens from my IdentityServer4 for every click as I don't expect the user to stay authenticated in the browser if zhe has logged out from SAP's Successfactor (or any other app linked with Azure).
Please advise, if I should generate refresh_token? Is it a good architecture?
Access token is used to prove the request is allowed to access the resource(such as api from ms or your custom api) and refresh token is used to refresh access token to make sure the access token isn't expired. Access token will expire in an hour by default and refresh token has 90 days.
At this point, we can easily find the refresh token is designed for some special scenarios because the expired time for refresh token is much longer than access token's expired time, but we can also generate a new access token in other way such as using msal or sign in again.
As you said in the question, you can generate an access token by one click and you don't expect users to stay authenticated for a long time. So I think it's unnecessary for you to use refresh token.
I set up a Connected App, a Python application to programmatically access Salesforce objects on behalf of a user (offline access).
The app works and I can generate an access_token:
$ curl https://login.salesforce.com/services/oauth2/token -d "grant_type=password" -d "client_id=MY_APP_CLIENT_ID" -d "client_secret=MY_APP_SECRET" -d "username=my#user.com" -d "password=my_password"
{"access_token":"00D09000000KDIX!AQoAQNi1234","instance_url":"https://my_instance.salesforce.com","id":"https://login.salesforce.com/id/12345/12345","token_type":"Bearer","issued_at":"1606401330889","signature":"abc/def"}
So far so good.
Now I wanted to switch to a web-server-based flow that uses refresh tokens, but I'm stumped. Where do I get the initial refresh_token to send alongside grant_type=refresh_token? The docs seem to assume I already have a refresh_token and just want to generate another access_token based off that, which is not the case.
What are the actual steps and necessary calls, end-to-end?
List of docs that I found and read, but made me no wiser:
https://help.salesforce.com/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5
https://help.salesforce.com/articleView?id=remoteaccess_oauth_refresh_token_flow.htm&type=5
https://developer.salesforce.com/forums/?id=906F0000000AgInIAK
https://help.salesforce.com/articleView?id=connected_app_create_api_integration.htm&type=5
Here's the Salesforce documentation on the Web Server OAuth flow. It runs like this; note that user interaction is involved, so curl by itself won't be enough to demonstrate the flow clearly.
You direct the user to the Salesforce login UI, in their web browser, to get yourself an an authorization code:
https://login.salesforce.com/services/oauth2/authorize?client_id=<YOUR CONNECTED APP CLIENT ID>&redirect_uri=<CALLBACK URL ON YOUR SERVER>&response_type=code
The user interacts with the authorization page to approve your application.
The user is then redirected to the callback URL in your application that you provided in the call (note: this also has to be set up as a callback in your Connected App definition), e.g.,
https://YOUR_SERVER.com/oauth2/callback?code=<AUTHORIZATION CODE>
Your app can present UI here if you want but the point is to ingest the authorization code.
The callback URL can be on localhost. That's how, for example, the Salesforce CLI implements authorization of orgs; it spins up a local web server to receive the callback.
At this point, the user interaction is done. Your application makes a POST request to Salesforce's /services/oauth2/token endpoint to exchange the authorization code you received for an access token.
If your Connected App is set up with the refresh_token scope, you'll also get back at that time a refresh token that you can store and use to obtain new access tokens in the future, using the refresh token flow you already identified.
For a headless application, it can be easier to go straight to JWT (if that's your ultimate goal). I have an example of how to pair JWT authentication with the simple_salesforce Python library. It takes a little bit of initial setup to populate the certificate on the Connected App and assign Preapproved Profiles (or better, Permission Sets), but once the setup is done it's very smooth and never requires any user interaction.
I am having troubles in implementing OAuth in the right way.
I use a client/API architecture (Angular for front and Node.js for back) and I would like user to sign in using Google OAuth authentication only.
Here is what I think is the right way for the moment (tell me if I misunderstood something) :
Angular open a Google popup asking user's consent.
Once the user agree, Google Authorization server sends back to angular a verification code.
This verification code is forwarded to an API endpoint.
Then, the API asks Google Authorization server to exchange this code for an access_token, an id_token and a refresh_token.
Google sends those 3 tokens.
The API uses access_token to retrieve user from Google API
The API persists the user
Here is the little dillema, in my opinion, the access_token and refresh_token should be stored into the database and the id_token should be sent back to Angular client.
This way, it would allow the API to ask for resource in Google API and if the token expires it can still ask for a new token thanks to the refresh_token.
Client-side, the id_token is embedded in all requests thus allowing the API to identify the client and verify his authentication with Google certs from https://www.googleapis.com/oauth2/v3/certs.
Supposing this is right way to use tokens, how could I deal with id_token expiration since client does not have any refresh token ?
Thanks !
I do it slightly different (I have the same basic architecture though).
Angular decides the user needs to log in and displays a login popup.
The url in the login popup is not serviced by angular, but is instead directly run off of the backend server: /auth/google . (I use hapijs and bell, personally).
/auth/google is serviced by a bell plugin and initiates the OAUTH dance.
the end of the OAUTH dance results in my node server generating a local token (I just generate random bytes and store them in redis mapped to user ids)
because the initial login popup was created by window.open, the success page (generated on the api side rather than in angular) can use window.opener.postMessage to communicate the token back to the angular runtime.
This way, all my sensitive google credentials (the user's oauth token, refresh token if needed, and my application's api ID and secret) are only on the server, except for during the OAUTH dance relay when they're in a URL string during the client redirects. This is reasonably secure.
Then for all the actual user interactions with the api, I use the token I generated in step four to authenticate. This could be a JWT if you wanted, but I don't do it that way; I just use redis to map from 'longrandostring' -> userId. That lets me (for example) force everyone to re-login if I wipe the redis database that has all the tokens stored, or I can write a lua script to delete all the entries that map to a certain userid.
If you need a refresh token, you can set access_type=offline in the initial request to oauth2/auth, and you'll get a refresh token as part of the response, unless you've previously gotten a refresh token. You can then persist it on the server side and get new access tokens as needed. If you set approval_prompt=force as well, you'll force a new consent screen and be guaranteed a refresh token (but after some small number of refresh tokens granted to a user, older ones expire on the same application so it's best to only request them if really needed).
I am building a glass app using the PHP sample app as reference.
To my understanding, the glass app is a web app which is user facing. When the user visit the web app, they will authorize the web app (using oauth2) to access their resources, and once authorization succeeded the web app will get an access token, which is then saved in a sqlite database (there's this store_credentials() function which stores the access token).
So if I have 100 users who visit the web app and register, the database will hold 100 access tokens for these users. Let's say I have some backend code which pull from a RSS feed every hour, and whenever I find there's a new story I will push it to all registered users. Let's say I have a cron job which does this, when when this job is triggered, I will find all the access tokens in the database and use them to make mirror API calls to insert cards. But what if some of the access token is expired when I am trying to make the mirror API call? It seems I will need to ask user to re-authorized, but at this point I am not interacting with the user. If I have a refresh token, I may be able to call oauth again to get a new access token.
Thanks.
You pretty much answered your own question - when you request permission using OAuth, you should also request "offline" access. The first time you do this for each user it will give you a refresh token along with your access token, and you should store both. If you did not request offline access initially, you will need to revoke the tokens that have been granted and re-grant them with offline access.
If the sample app you're referring to is the one at https://github.com/googleglass/mirror-quickstart-php, all this should be done for you already with the libraries included. The credentials returned from $client->getAccessToken() in oauth2callback.php should include both the access and refresh tokens, and these are saved in that same file by calling store_credentials(). The client libraries should check if the access token has expired and, if so, it gets a new one with the refresh token before making the call.
You may want to take a look at the contents of the credentials object at these various points and make sure there is a refresh token. If not, try revoking all the tokens and starting again, since it sounds like the first time you authorized the client you did so without requesting offline access.
If you are doing this yourself, best practice is to either refresh the access token if it has expired or is about to expire (since there may be some delay) before use, or (even better) attempt to make the call with an access token and, if it fails with an authentication error, get a new access token via the refresh token and try again.
I'm developing an AngularJS app used by third part applications. The third part application and my AngularJS application have a common database where users preferences/credentials are stored. User can login from the third part application and, by redirecting the user into my application, I need to maintain the user logged in, without asking a new authentication procedure.
I can't use cookies because the two applications are in two different domains.
I can't pass a session TOKEN (correspondant to the user logged iin) in query parameters due to man in the middle risks.
Is it possible to make a POST request to an angularJS page? Third part app call my AngularJS login page POSTing a token in the body request. My app take the token, verifyies it and log-in the user.
Constraints:
App in different domains;
Maintain user logged in;
No sharing cookies;
Try to prevent man in the middle;
No query parameters;
HTTPS protocol;
web based applications.
Am I missing something in the https protocols/sharing sessions?
Are there other solutions supported by AngularJS?
How can I redirect the user from one application to another and maintaining the user logged in in a simple way? Is there a simple flow I haven't figured out?
AngularJS is based on REST api communications. I can ask for a webpage (GET the webpage), but I can't make a POST to an AngularJS page. Is there a way to pass/share some values from the first application to my second app in a secure way?