OAuth 2.0 + on single page Applications

OAuth 2.0 From Single Page Application Assisted Token

Wednesday 8D

Convener: Daniel Lindau

Notes-taker(s): Mark Dobrinic

Tags for the session – technology discussed/ideas considered:

OAuth, Single Page Applications, Assisted Token flow

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Recently Implicit Flow was deprecated, what should be next. Instead of forcing a SPA into the code flow, the "assisted token flow" draft describes how that could solved with a new flow.

It is based on a new endpoint, /assisted-token. On this endpoint, the client can be even more simple than with implicit flow.

Upon initiating the flow, the AS returns a document that uses JavaScript postMessage to follow up whether the user needs to be authenticated.

Noted that this could be vulnerable for phishing attack.

The result is that the AS returns a page in the IFRAME that post back the access token to the framer through a JavaScript postMessage.

The AS serves up all the library code to perform the assisted token flow, which does not involve the client to invent this.

The token is issue from the /assisted-token endpoint, and not from the /token endpoint.

The client needs to identify, so the AS can respond with pages that are protected to be served under known client domains.

The assisted token flow only specifies how to get a token; it's up to the app to use it for requests to the Resource Server.

Storing the Access Token in a cookie helps protect it after the SPA receives it.

Suggested benefits - No need for CORS on the token endpoint (reduces complexity) - The implementation is provided fully by the AS (hidden from the client)

Ease of use is the goal, in particular ease of use for client developers.

Valuable take-aways: - provides good libraries - provides a flow without redirections

Some concern: how can this approach be generified? It's not a general solution as it is. Then again: it doesn't necessarily needs to be generic.

Make sure to relate this draft to OIDC's Session Management spec.

Considering the opinion to prefer adding the complexity to the token endpoint, not to have to expose a new endpoint.

Post the link of the draft to the OAuth list again:

User Interaction needs to be in a pop up, so postMessage can still reach the opener-frame.

Also see old spec: webmessage post back response mode.

Be careful: prefer not to open AS in an iframe ever.