CODEWITHSUNDEEP
oauthsingle-page-applicationopenid-connect
Mike Rowley
Mike Rowley

Reputation: 958

OAuth/OIDC - How To Manage SPA Web App Component Visibility

With OAuth we configure an "Authorization Server" (STS) with one or more "clients" (i.e. SPA web app). Those clients are configured to allow access to one or more "resources" (i.e. API). When a client initiates an OAuth flow (i.e. Authorization Code + PKCE) a "resource owner" (user) is authenticated and at the end of the "flow" an "Access Token" (and maybe a refresh token) is provided to the client which can now be used to access resources (API).

Lets assume that the Access Token is a JWT with claims and that the client now has the ability to read those claims.

UI and component visibility is something that I'm not sure I have done correct in the past:

As the access token's intent is really to drive API access is it wrong to also use it to drive UI component visibility (i.e. determine if we should show a menu item or enable an edit button based on JWT claims in the access token)?

A concern here is we could start adding claims that are really just for the UI / web app out of connivence and have nothing to do with a resource.

Note: it should be obvious that "hiding" a menu item in a web app does nothing to actually protect a resource so this is more about user experience

Or - should we be using the OIDC User Info endpoint and have it configured to provide enough information to drive the UI experience?

Or - should we have an API endpoint that will return a payload that describes UI component visibility for the current user?

Or is there another recommended approach that should be used?

Upvotes: 0

Views: 202

Answers (1)

Gary Archer
Gary Archer

Reputation: 29218

As you indicate, it is not recommended for UI clients to use claims in access tokens. They are intended only for use by APIs.

A common pattern is to enforce this by issuing access tokens to clients in a confidential opaque / reference token format, such as a UUID. This can also be a more secure way of dealing with sensitive claims, such as personally identifiable information (name, email etc).

The client also receives an ID token, and personally I prefer to limit ID token claims to protocol claims such as when and how the user authenticated. This ensures that you don't inadvertently reveal PII, eg in logout redirects. A client can get identity fields such as name and email by sending the access token to OAuth user info endpoint.

When fields are more domain specific it can make sense for the client to get its security rules from an API endpoint, that can be tailored to what the client needs. This might include whether orders are editable, which columns the user is allowed to see, and so on. If preferred, the SPA can make a single call to the API, which looks up user info, then returns a transformed result.

Sometimes SPAs use a backend for frontend, in which case the main difference is that the UI receives HTTP-only cookies. In this case the same techniques transfer naturally, where the UI must ask the backend for user info, claims and security rules.

Upvotes: 1

Related Questions