<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D51Y00005xyT6jSAEOkta Classic EngineSingle Sign-OnAnswered2024-06-30T10:47:38.000Z2019-02-13T15:07:34.000Z2020-03-04T08:18:27.000Z

jrad9 (jrad9) asked a question.

SPA OAuth Flow Recommendation and Token Refresh

We are re-evaluating which OAuth flow to use with a React SPA and have found some conflicting information on SPA recommendations between the Okta docs and information published by the security community.

 

According to some recommendations from the security community (eg. https://www.oauth.com/oauth2-servers/single-page-apps/, https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11), it is currently recommended that single page apps use the authorization code flow for issuing access tokens. According to the second link, "clients SHOULD NOT use the implicit grant... unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented". It’s unclear whether Okta meets this requirement.

 

In conflict to this, the Okta docs recommend the use of the implicit flow for single page apps (https://developer.okta.com/authentication-guide/implementing-authentication/implicit). Also, Okta’s implementation of the authorization code flow requires that the client secret be included when exchanging the authorization code for an access token (https://developer.okta.com/authentication-guide/implementing-authentication/auth-code). This seems to rule out the use of Okta’s authorization code flow from SPA’s. Some other OAuth implementations do not require authenticating with the /token endpoint, and make this flow possible to use from SPA's without needing the client secret.

 

Another requirement we’re trying to balance is to allow refreshing the access token from the client so the user is not repeatedly required to login. We do not believe this is possible with the implicit flow, other than increasing the expiration time or by occasionally redirecting away from our application using an approach like this (https://devforum.okta.com/t/refresh-token-in-implicit-flow-oidc-spa-apps/2015).

 

Do you have any advice or recommendations?


jrad9 likes this.
  • Hi Drew,

     

    Okta has implemented implicit flow as defined in RFC 6749, section 1.3.2. 

    https://tools.ietf.org/html/rfc6749#section-1.3.2

     

    1.3.2. Implicit

     

      The implicit grant is a simplified authorization code flow optimized

      for clients implemented in a browser using a scripting language such

      as JavaScript. In the implicit flow, instead of issuing the client

      an authorization code, the client is issued an access token directly

      (as the result of the resource owner authorization). The grant type

      is implicit, as no intermediate credentials (such as an authorization

      code) are issued (and later used to obtain an access token).

     

    The security risk that might occur when using implicit flow is that the JWT tokens are exposed directly in the browser and, as such, they can be intercepted in a man-in-the-middle scenario.

     

    To prevent this, customers can integrate authorization code flow using OpenID Connect web apps, which indeed requires both client ID and client secret to be passed. This is because the request to /token endpoint must come from server side, rather that client side. As such, the /token endpoint on the authorization server is not CORS enabled.

     

    Our engineering team is aware of new OIDC flow scenarios such as the one that is presented on oauth.com. At the moment, we do not have an estimated time for when they will be released, however I invite you to follow our product roadmap at https://support.okta.com/help/s/productroadmap.

     

    Regarding refreshing the access tokens, we have provided at https://developer.okta.com/authentication-guide/tokens/refreshing-tokens the method when using a Single Page Application. In short, we would require the application to access the /authorize endpoint with prompt=none GET parameter. In this way, the user will not have to reauthenticate every time, having both the Okta session and JWT tokens extended.

     

    Dragos Gaftoneanu

    Developer Support Engineer

    Okta Global Customer Care

    Expand Post
  • 05zdi (05zdi)

    @Dragos - The link you reference says"After you have an application, you need to make sure that the "Allowed grant types" include "Refresh Token"" but in our Okta SPA type apps do not have the option of Refresh tokens under "Allowed grant types". Without the grant type would it be possible for an SPI to refresh a token?

This question is closed.
Loading
SPA OAuth Flow Recommendation and Token Refresh