Arvados

Something like this:

      OpenIDConnect:                                                                                                                                                                                                                 

        # ...

        # Send additional scope values (along with "openid") in order to request additional claims. Space-separated, case sensitive.
        RequestScopes: "profile email" 

        # Verify that the following claims are returned by the provider (and not empty); otherwise, refuse login. Space-separated, case sensitive.
        RequireClaims: "" 

PA comments¶

my understanding was that the flow was something like this:

1. client sends user to login, and asks for a list of scopes. We could define scopes associated with arvados clusters as "arvados:clusterid" eg arvados:su92l"
2. User agrees to the scopes (or not)
3. List of scopes are stored as part of the token
4. The consumer of the token can check for a specific scope to see if the user authorized a given action

• some scopes are special and defined in the spec because they affect the behavior of the OIDC APIs
• token issuers can restrict the ability to request scopes by client id, so that e.g. mycoolwebsite.com wouldn't be able to get a token that has the "arvados:su92l" scope unless the provider granted permission to do so to mycoolwebsite.com's client id.

We need a new config knob for which scope(s) we require when accepting tokens that were issued for other clients.