Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Oauth2 Implicit Flow with single-page-app refreshing access tokens

I am using Thinktecture AuthorizationServer (AS) and it is working great.

I would like to write a native javascript single page app which can call a WebAPI directly, however implicit flow does not provide a refresh token.

If an AJAX call is made, if the token has expired the API will send a redirect to the login page, since the data is using dynamic popups it will this will interrupt the user.

How does Facebook or Stackoverflow do this and still allow the javascript running on the page to call the APIs?

Proposed Solution

Does the below scenario sound sensible (assuming this can be done with iframes):

My SPA directs me to the AS and I obtain a token by Implicit Flow. Within AS I click allow Read data scope, and click Remember decision, then Allow button.

Since I have clicked Remember decision button, whenever I hit AS for a token, a new token is passed back automatically without me needing to sign in ( I can see FedAuth cookie which is remembering my decision and believe this is enabling this to just work).

With my SPA (untrusted app), I don't have a refresh-token only an access token. So instead I:

  1. Ensure user has logged in and clicked remember decision (otherwise iframe wont work)
  2. Call WebAPI, if 401 response try and get a new token by the below steps...
  3. Have a hidden iframe on the page, which I will set the URL to get a new access-token from the Authorisation Server.
  4. Get the new token from the iframe's hash-fragment, then store this in the SPA and use for all future WebAPI requests.

I guess I would still be in trouble if the FedAuth cookie is stolen.

Any standard or recommended way for the above scenario?

like image 560
morleyc Avatar asked May 07 '14 12:05

morleyc


People also ask

How do you refresh an access token in implicit flow?

No refresh token is issued during the implicit flow, instead if a client needs additional access tokens it needs to re-authorize. If Curity is configured with Single Sign-On the re-authorization can happen without user interaction since the SSO session might still be valid.

Is the OAuth 2.0 implicit flow dead?

Summary. The Implicit flow is deprecated for web applications because the Authorization Code flow with PKCE is cleaner to implement. Note that at the time of this writing, no new attacks have been discovered against the Implicit flow. It's just a relic from a different web, which we no longer need today.

How does OAuth2 refresh token work?

The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired. This allows clients to continue to have a valid access token without further interaction with the user.

Why does OAuth v2 have both access and refresh tokens?

Having both Access and Refresh tokens means the attacker has more chance to access the user's account by being able to guess one of them.


2 Answers

I understand that your problem is that the user will experience an interruption when the access token has expired, by a redirection to the login page of the authorization server. But I don't think you can and should get around this, at least, when using the implicit grant.

As I'm sure you already know, the implicit grant should be used by consumers that can NOT keep their credentials secret. Because of this, the access token that is issued by an authorization server should have a limited ttl. For instance google invalidates their access token in 3600 sec. Of course you can increase the ttl, but it should never become a long lived token.

Also something to note is that in my opinion the user interruption is very minimal, i.e if implemented correctly, the user will only have to authenticate once with the authorization server. After doing that (for example the first time when also authorizing the application access to whatever resources the user controls) a session will be established (either cookie- or token based) and when the access token of the consumer (web app using implicit grant) expires, the user will be notified that the token has expired and re authentication with the authorization server is required. But because a session already has been established, the user will be immediately redirected back to the web app.

If however this is not what you want, you should, in my opinion, consider using the authorization code grant, instead of doing complicated stuff with iframes. In that case you need a server side web application because then you can keep your credentials secret and use refresh tokens.

like image 167
danillouz Avatar answered Sep 20 '22 05:09

danillouz


Sounds like you need to queue requests in the event that an access token expires. This is more or less how Facebook and Google do it. A simple way using Angular would be to add a HTTP Interceptor and check for HTTP401 responses. If one is returned, you re-authenticate and queue any requests that come in after until the authentication request has completed (i.e. a promise). Once that's done, you can then process the outstanding queue with the newly returned access token from your authentication request using your refresh token.

Happy Coding.

like image 45
Matthew Merryfull Avatar answered Sep 18 '22 05:09

Matthew Merryfull