Search code examples
oauth-2.0amazon-cognitoscopes

AWS Cognito Resource server identifier and scopes Resource server brings

I've read docs and seen this. Struggling to put Cognito + API GW + OAuth2 pieces together. My questions:

  1. Do I correctly understand the flow and use of Resource server scopes: client app asks the Cognito user pool for a JWT token (login/authorization happens). Request for a token contains custom scope A so as the Cognito returned JWT access token. After that client app uses obtained token making a REST API call to a "resource server" (say, to our configured API GW endpoint). API GW endpoint is set to use our Cognito user pool as authorizer + scope is set to be custom scope A. Thus scope here acts like a "role" or "permission": if client has a valid JWT token + this token has a custom scope A inside + API GW endpoint is set to use that scope - then client app is authorized to call API GW endpoint. Effectively it acts like a "resource-based IAM policy" for endpoint but no IAM is involved here.
  2. Do I correctly understand that AWS Cognito Resource server identifier is an arbitrary string? It is not the URI of a factual "resource server" (our API GW). URI format is used purely for uniqueness and there is no place in flow where Cognito Resource server identifier matters or somehow checked/validated? Also it looks like that Resource server identifier does not affect JWT token generation or token contents?

thanks for clarif.

Solution
    1. Application scope should not be confused with user permission. Scopes define the access an application has to the user's resources. Therefore resource access is the overlap of the two:
      • Check that the user has access
      • Check that the application has scope (access to user acccess)

    Example

    2 Clients with scopes:

    • A: E-Commerce (product:create, product:remove, order:create, order:update-status, order:read-status)
    • B: 3rd-party Order Tracker (order:read-status)

    2 Users with permissions:

    • Customer (order:create:owned, order:read-status:owned)
    • Admin (product:all, order:all)

    Therefore…

    • Customer PUT /product with client A = DENY due to missing user permission
    • Admin PUT /product with client B = DENY due to missing scope …
    1. By requiring a URI, AWS seems to enforce collision resistant identifiers as you point out. It's not a common practice and doesn't really have any real security benefit, nor is it validated by AWS that you control the resource.