We want to use the OAuth2 Implicit Grant as it is proposed for single page applications. For JavaScript applications which don't have a classic web session. The applications only have access tokens which expire after an hour. We use a central authentication service (CAS) where the user could posess a session.

At the beginning the user doesn't have any session. When the user starts the JS-application it navigates the user agent to the CAS where he gets authenticated via his credentials. After successful authentication he will be redirected to the JS-application with the access token in the fragment.

After short time the access token is not valid anymore and the application needs a new access token. For that the application navigates the user agent to the CAS again. The questions is: what should the CAS do?

  • The user already has a session at the CAS. Is it allowed to use this session to authenticate the user? In this case the user does not have to provide his credentials again.

  • The central authentication service could ask for the user's credentials again.

In my opinion asking the user for his credentials once in an hour is somewhat strange so I would prefer the first solution. But would it be a valid way to get a new access token regarding the OAuth2 RFC?

The RFC states "The implicit grant [...] relies on the presence of the resource owner". I think the first solution does not rely on the presence of the resource owner. For example, the resource owner could leave his computer for some hours but the JS applicatino is still running. If an access token becomes invalid the JS application can get a new access token just by navigating to the CAS which automatically authenticates via the session and redirects back to the JS application. This is done automatically without the presence of the resource owner.

The CAS could only be sure that the resource owner is present if it would ask for the credentials again. But that would mean to ask for the credentials every 30 minutes.

If these options don't apply, how could step (B) in Figure 4 in 4.2 of the RFC6749 be realized to renew access tokens?

3 Answers 3


If you control the CAS then it is upto you how you access a new access token.

Since your user has already authorised the SPA using your CAS, if the session is still valid with the CAS there is no need to ask them to reauthenticate using their credentials.

Of course, it is upto your acceptable risk level for how long they should remain authenticated at the CAS. If it is a high security application, then you may wish to reduce the session timeout or ask yourself why the access token expiration has been set to expire earlier than the CAS session timeout.

Original answer:

Take a look at the Refresh Tokens section.

The session being valid at the CAS should mean that the user agent has a valid refresh token - this is what is needed in order to renew the access token for the user.

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires

Correction: Refresh Tokens are not to be issued for implicit grants.

The authorization server MUST NOT issue a refresh token.

The "presence" of the resource owner is only relied upon for initial authorisation.

  • I think I still don't get it. Refresh tokens are issued to the client. Ok. But here the client is the JavaScript application and due to the implicit grant no refresh tokens are issued to that client which could be used to obtain new access tokens.
    – DanielE
    Commented Aug 9, 2016 at 22:01
  • 1
    Apologies, just realised that refresh tokens are not used in implicit grant. Answer updated. Commented Aug 10, 2016 at 8:16

I think the relevant section of the spec (section 4.2.1) is this:

If the request is valid, the authorization server authenticates the
resource owner and obtains an authorization decision (by asking the
resource owner or by establishing approval via other means).

In order to authenticate a user, you are given the option of either "Asking the resource owner" or "Establishing via other means". The former usually means login credentials. The latter can mean anything from ssh auth, to cookies, to calling up the user's phone number and asking them to provide a voiceprint sample by singing Barnes & Barnes' "Fish Heads".

In short: Using the session on CAS is fine, and well within the spec.


Nowadays one of the best options¹ for SPAs is to use the authorization code grant with PKCE. The implicit grant will be banned from spec in OAuth 2.1 due to its flaws – The implicit grant has no real advantage over the code grant but has major problems regarding security.

By using the authorization grant, you are also able to use refresh token to refresh the access tokens. This requires no interaction of the user.

¹) Another is also using authorization code and PKCE but with a confidential client and the BFF (Backend for Frontend) pattern, where the backend does all OAuth stuff and leaks no token to the frontend which is more secure than handling the refresh token in the frontend.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .