CODEWITHSUNDEEP
securityoauthoauth-2.0openid-connect
bLaXjack
bLaXjack

Reputation: 870

Single Auth model for SPA+API Server and Traditional Web Application (OIDC way)

I am in the midst of designing a single auth model that works for both SPA+API server and web applications. Got some insight from the here link to use access/id token in cookie form (none httpOnly) for web application integration.

enter image description here

Attempting the OIDC public client and PKCE way, the integration is workable for SPA+API server but I am stuck at the token renewal flow for the traditional web application. Oidc silence renewal flow is pretty front channel initiated and when the access token is expired, what will be the options for web application to retrieve the new access token ? (assuming the session from IdP is not expired)

enter image description here

Upvotes: 1

Views: 664

Answers (1)

Travis Spencer
Travis Spencer

Reputation: 2271

You should use the OpenID Connect hybrid flow. This will issue tokens to your front-end and traditional back-end Web app. It will also allow you to issue different kinds of tokens with different claims to each.

More specifically, the front-end may only get:

  • An ID token; or
  • An ID token and access token; or
  • An ID token and access token and a refresh token.

Also, the back-end may only be issued any combination of these.

You can test the hybrid flow if you're unfamiliar with it using oauth.tools.

For the front-end, you have a couple option to continue access the protected resources without prompting the user:

  1. Rely on SSO (the front-channel approach you mention) or
  2. Issue the SPA a refresh token

In the refresh case, take note of the best common practice for this:

  1. The refresh token should be created anew whenever it's redeemed
  2. Refresh tokens must expire by a certain time or after a certain period of inactivity
  3. Renewed refresh tokens must not be renewed beyond the lifetime of the original

If you do these things, there's still risk involved in issuing an SPA a refresh token, so consider:

  1. Not issuing one or
  2. Doing a combo of the two approaches

When doing a combination (SSO + RT), you could cap the lifetime of the refresh token to something that shouldn't greatly impact the user's interaction with the API while still requiring them to prove control of the original credential with some amount of frequency that offsets the risk. In such a case, the friction of having to login could be lessed by allowing SSO at the authorization server. This too introduces risk, so its lifetime should be limited.

I would look at all these timeouts as knobs that you can turn and twist to ensure an adequate amount of security.

Extending the period of access for the traditional, back-end application can be done using the same two options (SSO or RT).

Upvotes: 1

Related Questions