4

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?

Improve this question
9
  • I think i saw your other question. I'm confused by your interpretation of these 'widgets' as entities with authorisation in their own right. are they owned by different companies or something? Commented Oct 30, 2017 at 11:37
  • @Ewan My other question is unrelated. The "widgets" are small web apps (ideally webcomponents) written by various teams inside our large company. An example of a widget would be a chart that displays some data private to the user. Commented Oct 30, 2017 at 12:18
  • and in creating the widget your org has decided to show that info to users right? theres no question of the widget having too much access. You can give it full rights to the data. you only care whether the user should be allowed to use widget Commented Oct 30, 2017 at 17:45
  • How are you handling authorization? The access_token represents authentication OK, but is too opaque to be used for authorization purposes. JWT (the id_token) can include the roles or any application specific values which can be further used by each widget. I agree, multiple authentications are less than ideal, but can be handled without user interaction. That's similar to how Atlassian JIRA's dashboard works. Unless you have full PKI that requires you to enter a pin, it's invisible to the user. Commented Oct 30, 2017 at 17:55
  • @BerinLoritsch I'm pretty sure that access_token means authorization, not authentication due to OAuth2 being an authorization framework. What do you mean by "can be handled without user interaction"? I'm under impression that users need to give their consent explicitly. Commented Oct 30, 2017 at 20:02

1 Answer 1

Reset to default
2
+25

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.

Improve this answer
6
  • 1
    "if [...] resource server is compromised, again having a different token per widget doesn't help" Why not? We have multiple resource servers. A compromised resource server might legitimately call another server using a token with all scopes. Commented Nov 7, 2017 at 10:53
  • If you have multiple resource servers, and you're concerned one of them could be compromised then you can have one token per resource server so access token that grants access on one resource server is not seen by the other server. Commented Nov 7, 2017 at 18:05
  • But then I'm back to the original problem of multiple access_tokens which means a redirect per token. Also, it's more complicated than a token per widget. Commented Nov 7, 2017 at 20:40
  • IMHO, this is a different problem. The client can get a refresh token from the authorization server with scopes needed across all resources. Then, as per RFC 6749 section 1.5, it can use the refresh token "to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner)." Essentially, the client can use the refresh token to get one access token per resource server with scopes that give it access only to that resource server. One server cannot then use a client's token to access another. Commented Nov 8, 2017 at 7:57
  • In Implicit Flow there's no refresh token. Commented Nov 8, 2017 at 9:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.