oauthlib/Lobby

Discuss about OAuthlib framework

chbndrhnns

@chbndrhnns

Hey there, does someone know about efforts for making oauthlib available for FastAPI?

Jonathan Huot

@JonathanHuot

hi @chbndrhnns , fastapi seems very close to the bottle framework. So I guess the effort is similar to bottle-oauthlib (one simple file providing decorators)

agarwalvishakha18

@agarwalvishakha18

Hey. I have upgraded oauthlib to 3.1.0. I am using the library for my auth test cases. They are failing now and the error coming is http://paste.openstack.org/show/764384/

Can anybody help in there

Jonathan Huot

@JonathanHuot

Hi @agarwalvishakha18 , let me see

do you have the code called whhich hgenerate the exception please?

agarwalvishakha18

@agarwalvishakha18

Thanks for the reply @JonathanHuot . Here I have pasted the whole backtrace http://paste.openstack.org/show/764541/

Jonathan Huot

@JonathanHuot

Hi @agarwalvishakha18 , it seems flask is providing a class which is kind of hybrid between list & dict and provide this error because of this. I'm not seeing any recent changes in Keystone or in oauthlib, so I'm thinking it's a longstanding issue

a quick fix will be to provide a dict instead of the werkzeug.datastructures.EnvironHeaders type; e.g.

adds: headers=dict(flask.request.headers) in create_request_token_response

at line https://github.com/openstack/keystone/blob/master/keystone/api/os_oauth1.py#L230

agarwalvishakha18

@agarwalvishakha18

Thanks @JonathanHuot for the quick help :)

agarwalvishakha18

@agarwalvishakha18

@JonathanHuot Got another error http://paste.openstack.org/show/764714/

Jonathan Huot

@JonathanHuot

yes, that's the same error than before. You need to add dict() around flask.request.headers

agarwalvishakha18

@agarwalvishakha18

Hi @JonathanHuot, it isn't having any impact over it. https://review.opendev.org/#/c/677511/ , the result is still same.

Jonathan Huot

@JonathanHuot

Hi, basically you have to pass a dict to this function. If you are passing another type, it's unlikely to work. Not much we can help here

agarwalvishakha18

@agarwalvishakha18

@JonathanHuot Thanks for the help.

Jonathan Huot

@JonathanHuot

@agarwalvishakha18 : you're welcome, don't hesitate to ask other questions if you have other errors with the oauthlib interfaces!

Anthony

@tribals

Hi there

I'm stuck with scope validation on authorization request.

Anthony

@tribals

According to spec, authorization server may partially or fully ignore the scopes passed by the client. That is, if I understand correctly, scopes requested by client is completely optional. Authorization Server must not respond with invalid_scope error if authorized user doesn't have scopes requested by client. Rather, resulting authorized scopes in this case simply should be reduced to user's scopes, is it? Is it correct that AS respond with invalid_scope error if and only if scope parameter is malformed, or client requested scope(s) that doesn't exist at all?

Anthony

@tribals

Here is the implementation of validate_scopes from GrantTypeBase:

File: oauthlib/oauth2/rfc6749/grant_types/base.py
77: class GrantTypeBase(object):
<...snip...>
166:     def validate_scopes(self, request):
167:         """
168:         :param request: OAuthlib request.
169:         :type request: oauthlib.common.Request
170:         """
171:         if not request.scopes:
172:             request.scopes = utils.scope_to_list(request.scope) or utils.scope_to_list(
173:                 self.request_validator.get_default_scopes(request.client_id, request))
174:         log.debug('Validating access to scopes %r for client %r (%r).',
175:                   request.scopes, request.client_id, request.client)
176:         if not self.request_validator.validate_scopes(request.client_id,
177:                                                       request.scopes, request.client, request):
178:             raise errors.InvalidScopeError(request=request)

In which case request_validator.validate_scopes should return False in order GrantTypeBase.validate_scopes to raise InvalidScopeError?

Benjamin Cordes

@benjyz

authlib links to https://github.com/lepture/flask-oauthlib which says "You should use https://github.com/lepture/authlib instead."

kind of confusing

Jonathan Huot

@JonathanHuot

Hi @benjyz, if you are looking for using oauthlib, you have multiple active projects which are bottle-oauthlib, django-oauth-toolkit, flask-dance. However flask-oauthlib is no longer maintained and the author rewrite the project w/o oauthlib framework and is now called authlib.

Hi @tribals , I think the doc could be improved

Jonathan Huot

@JonathanHuot

@tribals, as I read it from the RFC, it depends of the AS policy. If you does not allow a default scope, then return False in validate_scopes when request.scopes is empty (and let get_default_scopes returns nothing).

If your AS policy allows that, Then, if request.scopes is empty, return True :)

Anthony

@tribals

Is it correct that RequestValidator.validate_scopes does nothing with actually authorized scopes. I mean, scopes that will be returned in response?

Jonathan Huot

@JonathanHuot

you have to update request.scopes to the reduced list of authorized scopes, if any

& then return True / False as we said

Anthony

@tribals

Ok, got it. Thank you!

Jonathan Huot

@JonathanHuot

however improvement of the docstring of validate_scopes will be helpful if you want to do a PR that's welcomed :D :D

Tim Van den Eynde

@Timvde

Why is oauthlib parsing GET parameters? https://github.com/oauthlib/oauthlib/blob/master/oauthlib/common.py#L395

The spec says: "The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters.", but it does not say the query parameters need to be interpreted

Ow, nvm, I misread it.

Tim Van den Eynde

@Timvde

It makes no sense though

Jonathan Huot

@JonathanHuot

Hi @Timvde, for /authorize parsing GET parameters makes sense, however for POST it doesn't. Are you looking for something in particular ?

Tim Van den Eynde

@Timvde

No, one of our users was doing a POST to get a token with his password in the GET parameters (which works), so we were looking into whether that was valid

It makes no sense, but if I read the spec correctly, it is still valid

Oh, unless... "The endpoint URI MUST NOT include a fragment component."

I'm still new at reading specs, so I'm not sure what that means exactly

Tim Van den Eynde

@Timvde

Oh, or is a fragment the part after a #? In that case, nvm

I think it's technically valid

Jonathan Huot

@JonathanHuot

@Timvde , if you want to continue to use query argument with POST you may want to pinpoint the version <3.1.0 . You will have details in the RFC which states it MUST NOT be in the query. See https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485000169 . Quote: "The parameters can only be transmitted in the request-body and
MUST NOT be included in the request URI."

Tim Van den Eynde

@Timvde

I actually don't want to allow it, I just thought I had to after reading the RFC...

But if it isn't actually part of the RFC and updating oauthlib solves it, I'll glady perform the upgrade and disallow it

Jonathan Huot

@JonathanHuot

that's great! you can read the part mentionned in the #666 ticket and let us know if you have any questions

Tim Van den Eynde

@Timvde

Thank you for your help :)

Where communities thrive

People

Repo info

Activity