[Openid-specs-ab] Hybrid (browser + server) Relying Parties

Pedro Felix pmhsfelix at gmail.com
Sat May 12 15:07:49 UTC 2018


I've a question regarding "hybrid" (browser + server) relying party
scenarios in the context of the OIDC spec and I would like your opinion.

A common setting in modern apps, is for them to be composed by
- a rich javascript client
- a backend HTTP API
Both components typically access to the user's identity (e.g. for UI
purposes or for access control purposes). Also common is the usage of
external identity providers (e.g. Google accounts) to obtain elements of
the user's identity.

A way to architect this in the context of OAuth 2.0 and OIDC would be to
use an "intermediate" Authorization Server (AS), where:
- The AS delegates authentication to external identity providers, i.e., the
AS would be the RP to the external IdPs.
- The browser-side app acts as the "client app" to the AS, and obtains
access tokens and ID tokens from the AS (e.g. using the "hybrid flow").
Then, uses the access tokens when accessing the backend HTTP API.
- The backend HTTP API app acts as the Resource Server to the AS and uses
the identity embed in the access token (as well as other authorisation
information such as granted scopes).

However, I was wondering if we really need this "intermediate"
Authorization Server. Namely. can't the browser-side app obtain ID tokens
directly from the external IdP (e.g. Google accounts) and use this ID token
to authenticate the user to the backend HTTP API. For instance, something
like this:

browser-app --> IdP: OIDC authorisation request
browser-app <-> IdP: ... authentication and consent ...
browser-app <-- IdP: ID token
browser-app --> backend API: ID token
backend API validates the ID token, including the audience, and generates
an access token
browser-app <-- backend API: access token
browser-app --> backend API: "application request" with access token as a
Bearer token

Does this last design make sense? Namely, does this relate to RFC 7523?

A variant would be to use the ID token as an access token on all
"application requests" done from the browser-app to the backend API,
however this seems to go agains the semantics of ID tokens.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180512/c9ddaed8/attachment.html>

More information about the Openid-specs-ab mailing list