API Access Management: How do you know what scopes to request from a custom app on behalf of an end-user based on their "role"?

Questions
1

Using the Angular dev guide, I already have my own SPA handling logins using redirect:

  login(originalUrl) {
    // Save current URL before redirect
    sessionStorage.setItem('okta-app-url', originalUrl || this.router.url);

    // Launches the login redirect.
    this.oktaAuth.token.getWithRedirect({
      scopes: ['openid', 'email', 'profile']
    });
  }

  // Executed on /callback
  async handleAuthentication() {
    const tokenContainer = await this.oktaAuth.token.parseFromUrl();

    this.oktaAuth.tokenManager.add('idToken', tokenContainer.tokens.idToken);
    this.oktaAuth.tokenManager.add('accessToken', tokenContainer.tokens.accessToken);

    if (await this.isAuthenticated()) {
      this.observer.next(true);
    }

    // Retrieve the saved URL and navigate back
    const url = sessionStorage.getItem('okta-app-url');
    this.router.navigateByUrl(url);
  }

How do I adapt this code, or change my access policies, such that I can ask for the right scopes for my end-users?

Presently I have 4 custom scopes and 3 groups (representing roles) that determine which subset of those 4 scopes they get.

2

I’m not sure I follow your use case. Are you trying to request specific scopes based on the user?

If only certain users should have access to certain things, (and it seems to be the case, given your description), you may want to look into using claims (such as a Groups claim) to pass this information along to your application.

For example, say you have an “App_Admin,” “App_Reporter”, and “App_EndUser” groups in Okta. With a groups claim configured for your authorization server (technique varies based on which type of server you are using, details for how to configure it for each found in our docs), you could pass group membership information for a user into a single claim. So, if a user in all three groups logs into the application, a claim in their token will indicate they are a member of all three groups and your application can use this information to grant them access to the appropriate resources.

3

I’m not sure I follow your use case. Are you trying to request specific scopes based on the user?

Yes. This exactly.

Given 3 groups: role_admin, role_standard, role_readonly
And 4 scopes: users.manage, users.read, orders.read, orders.manage

An end-user joe@example.com in group role_admin should get all 4 scopes.
An end-user bob@example.com in group role_standard should get only 3 scopes (users.read, orders.read, orders.manage)
An end-user liz@example.com in group role_readonly should only get 2 scopes. (users.read, orders.read)

In order for the Authorization Server to mint a token with those appropriate scopes, you need to know what scopes to ask for.

With a groups claim configured for your authorization server (technique varies based on which type of server you are using, details for how to configure it for each found in our docs), you could pass group membership information for a user into a single claim. So, if a user in all three groups logs into the application, a claim in their token will indicate they are a member of all three groups and your application can use this information to grant them access to the appropriate resources.

I understand claims are more flexible, and putting groups into a claim would be very straight-forward, but we want to take advantage of the features scopes provide.

4

Does it make more sense to rationalize the scopes as a way to permit access to the calling application (in this case an SPA web portal) and leverage claims to represent the user’s constraints on the data that is being accessed? (e.g. an Orders API)

In other words, the SPA web portal would always be minted tokens with the following scopes: users.manage, users.read, orders.read, orders.manage.

But then there is a claim of role also minted in the token with a value of admin, standard, or readonly.

The Orders API would then first check if they have the correct scope then check if they have the correct claim.