-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Add Device Code authorization to the supported OAuth Flows #2401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@MikeRalphson Let me know if those changes I made look good to you. :) |
@darrelmiller I was going through the unmerged PRs that were automatically closed when the |
I wouldn't mind resubmitting against v3.2.0-dev. I'll wait and see what Darrel says before I do so, though. |
Any updates on this? I am really looking forward to it! |
I would like to see support for oauth2 device code included. @darrelmiller can you progress this PR or otherwise help? |
There's probably no harm in filing the PR again against 3.2.0. That said, we might be headed towards a 4.0 version instead (even though it's in very early stages). I think having the PR will keep a reference alive for something that should be looked at. |
@webron I'm unsure if that means you want me to file against 3.2.0. Do you want me to, or would you prefer I wait and see what happens? In either case, I also want to mention: I have no qualms about someone (whether you, omz13, or someone else) copying and remaking my PR (whether wholesale or edited). So if you feel that might be easier than having me resubmit, then by all means do so. |
I'm referring to the 3.2.0 dev branch - https://github.com/OAI/OpenAPI-Specification/blob/v3.2.0-dev/versions/3.2.0.md. To be honest, if we wait and nobody files it, there's a decent chance we'll forget about it because there won't be any active reminder. |
@webron ...So you want me to resubmit this against the 3.2.0 branch, correct? |
Yes please. |
Okay. I will do so soon then. |
Closes #2381.
This is a PR for the Device Authorization OAuth Flow, based on RFC8628. I suggested this over at #2381 and was asked to make a PR for it.
The URL used for this flow is named
deviceAuthorizationUrl
, separate fromauthorizationUrl
as the two have completely different semantics and usages, so I was concerned that usingauthorizationUrl
for both might be confusing. That said, I would be happy to merge this intoauthorizationUrl
if requested.Also, I originally made a comment that this flow may benefit from a optional
deviceCodeFormat
field. However, I looked at the RFC again, and found that I originally misread the RFC -- the authorization server is the one that creates the code to be used, not the client wanting authorization.