Mixing authorization code and implicit grant type in OAuth2

1
votes

I have some questions for the following flow involving OAuth2:

webapp1.xyz.com is a registered client with authorization code grant type, here's the current flow:

  1. User logged in and redirected with authorization code to webapp1.xyz.com
  2. webapp1.xyz.com exchange authorization code for access token and store it to session
  3. webapp1.xyz.com server side needs to make calls to webapp2.xyz.com api by passing on access token
  4. webapp1.xyz.com has SPA where ajax calls webapp1.xyz.com api end point (passing on session cookies in request)
  5. User logged out, session is destroyed

There is a suggestion from someone to make the ajax call using (implicit grant) access token instead of session cookies. Is that even possible mixing authorization code and implicit grant type? Maybe I am mixing something, I cannot see any reason why using implicit grant type for the ajax part.

1
javascriptajaxoauthoauth-2.0single-page-application
Possible duplicate of stackoverflow.com/questions/7522831/…. I think this link answers your question. – Andrew

1 Answers

3
votes

Is that even possible mixing authorization code and implicit grant type?

The problem is more that you talking about one token for two applications. Or rather, webapp1 is both an OAuth client (web site which calls a web API - webapi2) and an OAuth resource (a web API which the SPA can call using implicit grant).

So: SPA javascript > webapp1.xyz.com application > webapp2.xyz.com application.

In Oauth2.0 terms your SPA client app would be a client, and webapp1 and webapp2 would be resources. the client would ideally use the implicit grant to get an access token as that's the optimised flow for a public, javascript client.

If possible, maybe look at a hybrid flow - OAuth2 and OpenID Connect - instead of the authorisation code flow.

Using the hybrid flow, webapp1 will get a token as currently, but it will also get an ID token which it can pass back to the SPA.

The ID token is intended for use by a client for authentication purposes - this ID token could do the same job the session cookie was doing (i.e. authentication between SPA and SPA backend). And the access token would be stored safely on the webapp1 server away from the SPA.