Multiple OAuth2 access_tokens on the same page

Question

We have been tasked with implementing a dashboard containing multiple widgets. The dashboard itself and all widgets need to access various secured APIs. Our authorisation protocol is OpenID.

Currently, the dashboard requests an access_token with all scopes required by all widgets. Widgets use this shared access_token to make requests to secure APIs.

The problem is, because this shared access_token has so many scopes, it is too "powerful". We are concerned that by using this shared token, widgets and APIs may have more rights than they are entitled to. Ideally we'd like that every widget has a separate access_token with its own scope.

I'm not sure how to achieve this. If every widget requests its own access_token, then the user will be redirected to authorisation endpoint multiple times. This is unacceptable for UX reasons.

We have considered wrapping widgets in iframes. So each widget can redirect inside of its own frame without affecting the dashboard. However, because they all run on the same domain, they can always access access_tokens of other widgets (because they are stored in LocalStorage), so I'm not sure this is better from a security perspective.

How can we architecture the authorisation system in a dashboard so that all widgets have their own access_tokens?

Answer 1

From a threat modeling perspective, it is not clear really what security benefit will you achieve by having each widget have its own token.

So unless it can be demonstrated that there is a clear security advantage (even if defense in depth), my suggestion would be to avoid adding complexity in your application, and keep it simple. Many security issues are caused by complexity.

For the case you present, let's look at the possibilities.

1. If the client is compromised, (that is, client in OAuth 2.0 parlance as per RFC 6749) it does not matter whether each widget has a different token or not, all of them will be compromised. Likewise, if authorization server or resource server is compromised, again having a different token per widget doesn't help.

2. If I were to really have a separate token for each widget, then the right model would be to have them as different clients with each having its own approved scopes that they can request from the authorization server. This will at least ensure that one widget cannot request a token with scopes that it is not approved for in requests to the resource server.

   However, based on your explanation, that does not seem to be the primary concern. (The only concern you have is that a single access token with too many scopes is shared by all widgets.) Even if it were, you would want to weigh it against usability because bad usability causes users to take shortcuts that you would want to avoid.

So based on these points, I would say that it does not seem to be a major security concern (unless I am missing something). If I were in your place, I might as well be happy getting one access token for the entire dashboard and using it as needed.

FYI, you may want to consult RFC 6819: OAuth 2.0 Threat Modeling and Security Considerations. I do not think that has anything related to this either.