Yes, the confusion is natural. All you need to know is that if it mentions the "Grant Type", most likely it's referencing the type of authorization, whereas if it mentions either "response_type" or "grant_type", that's the field name. Each "Grant Type" has a different combination of response_type/grant_type, so it is confusing. Ideally, the field grant_type in OAuth2 RFC would have been named differently .
Basically the "Grant Type" is the name of the Authorization flow. "grant_type" is the name of the field when sending request to the Token endpoint; "response_type" is the name of the field when sending request to the Authorization endpoint.
The flow can contains either only the Authorization endpoint (implicit), or both Authorization & Token endpoints (Authorization Code), or only token endpoint (client credentials). (+variants from OIDC world)
Basically the "Grant Type" is the name of the Authorization flow. "grant_type" is the name of the field when sending request to the Token endpoint; "response_type" is the name of the field when sending request to the Authorization endpoint.
Nice! Thanks for the clarification!
I'm being a bit silly here but I want to access the Meetup API via OAuth2 and was wondering when I write my client library do I actually need to spin up an Authorisation Server? Just so I can make requests?
Basically, if you just want to use public API, you just need a client (requests-oauthlib), or write your own client, hut that's often not needed.
I've been digging through the docs for the last week or so and I'm interested in adding some external authentication (oauth google login at first) to an existing aiohttp project. Is there any async support currently to help in this process? Otherwise, I'm looking at requests-oauthlib, when it is 'built' on oauthlib, does oauthlib provide the classes for the workflows and requests wraps the steps in the auth process? Do these wrappers do more? Just trying to figure out what it takes to implement a new project with oauthlib on its own
So it's up for our third-parties to implement those
@jaredvacanti Yes, you are correct.
I have integrated two PRs, feel free to read the documentation https://oauthlib.readthedocs.io/en/latest/oauth2/oidc.html and comment :)
if anyone want to submit PR, as long as it simplifies maintenance, then I'm good for it
We have a bunch waiting
With some, I don't know what to do
Especially when its related to OAuth1
did you see the bump in the nb of "used by" packages ? we were used by 30k repositories, now we're used by 55k repositories :o
Hi all
first of all, thanks for Oauthlib! Currently I'm looking into using requests-oauthlib in conjunction with yelp/bravado. However, I would have to implement some changes. Is anyone here familiar/responsible for requests-oauthlib? I would appreciate a small chat before initiating a public conversation (I'm not that familiar with open source / pull requests)
Thanks
first of all, thanks for Oauthlib! Currently I'm looking into using requests-oauthlib in conjunction with yelp/bravado. However, I would have to implement some changes. Is anyone here familiar/responsible for requests-oauthlib? I would appreciate a small chat before initiating a public conversation (I'm not that familiar with open source / pull requests)
Thanks
have you considered using a public oauth2 provider ?
Django-Oauth-Toolkit is implementing most of it though
but I not personally tested it; a lot of ppl is using it there.