Skip to content

Fix error handling for resource server requests #53

Description

@ThisIsMissEm

The RFC for Bearer tokens defines what should actually happen here, which is:

For example, in response to a protected resource request without
   authentication:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Bearer realm="example"

And in response to a protected resource request with an
   authentication attempt using an expired access token:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Bearer realm="example",
                       error="invalid_token",
                       error_description="The access token expired"

So the "correct" thing to do is to actually parse the WWW-Authenticate header if you get a 401, and then based on the error type (invalid_request / invalid_token / insufficient_scope) take an appropriate action. On invalid_token you would attempt a token refresh if you have an refresh token.

But for invalid_request or insufficient_scope, you want to just raise an exception usually. You can go more complicated on insufficient_scope if you know the authorization grant's scope contains the scope value from the WWW-Authenticate header params (if it is given), then you can perform a token refresh to increase the token's scope back to that of the authorization grant's origin scope. This is only used when you want to narrow scopes from an initial broader scope set on an authorization grant

Originally posted by @ThisIsMissEm in #50 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions