possible bug (or implementation library error)

[jvanasco]

I am having a problem with the oauth2 "token endpoint" and can't pinpoint the exact spot where the issue is. (I am using a custom library that is not released on github yet, but it's largely a port of flask-oauthlib onto the pyramid framework).

When submitting invalid credentials to (via http basic auth) to a token endpoint (e.g. server.create_token_response), the logic flow seems to make it to grant_types.client_credentials.ClientCredentialsGrant.create_token_response() and onto save_token without triggering any code to authenticate/check the user.

As a result, I experience an error trying to access the user.id in my token saving function, instead of having the library raise an exception earlier on.

Can someone suggest where I can look or what I can do to more correctly handle this?

[JonathanHuot]

Hi @jvanasco, could you add few details to understand the issue:

1. how did you created your server ?
2. the curl request with payload that you use?

The grant client_credentials does not require any user checking, so that is normal to me.

[jvanasco]

The request is coming in via requests

session = requests.Session()
basic_auth = HTTPBasicAuth(app_key, app_secret)
response = session.post('/oauth2/token_obtain', data= {'grant_type': 'client_credentials'}, auth=basic_auth)

The endpoint is basically:

server = oauthlib.oauth2.Server(custom_validator)  # validator is essentially flask-oauthlib
uri, http_method, body, headers = extract_params(self.pyramid_request)
ret = server.create_token_response(uri, http_method, body, headers, credentials)

To be clear, this is a malformed request that was expected to fail. This is from a test-suite of edge cases where people put in wrong information or omit it. This generated a bearer token to be saved, without a user.

I very likely made a giant mistake somewhere - I just can't find it. This logic flow seems like it should not be allowed.

[JonathanHuot]

The grant_type=client_credentials is only calling:

    authenticate_client()
    validate_grant_type (client_id, grant_type, client)
    validate_scopes(client_id, scopes, client)
    save_bearer_token(token)

The exact purpose of the client_credentials is to act on behalf of the client itself, not on behalf of the user.

[jvanasco]

The exact purpose of the client_credentials is to act on behalf of the client itself, not on behalf of the user.

Ah, I understand. I think my issue came from not properly porting/understanding flask-oauthlib.

Just to be safe...

In my use-case, a Client can either:

• obtain a token for itself (via client_credentials), and
• obtain a token on behalf of a user

Is the correct place to determine contact in save_bearer_token and inspecting request.grant_type ? If I have "client_credentials" there, then I have an application token. Otherwise for authorization_code it is a user token - correct? (and "refresh_token" can be either")

[JonathanHuot]

Yes, it is a safe assumption to use request.grant_type in your validator's methods like save_bearer_token.

[jvanasco]

okay, thanks for the clarification.

i'll close this and update the example app i built for my new library.