TODO: Provider - Device code #640

jcampbell05 · 2018-12-28T19:32:21Z

This PR focuses on the server implementation of #626 and leaves the client implementation for a future PR. Since its in a draft I have placed it in a draft folder to indicate this so those who need it can use it with the awareness it may change in the future and will be re-named when the specification is stable.

Device Code is a new authorization flow which allows a client to be authenticated by a user for a device with limited or no input.

I based this implementation on the authorization grant type since this flow shares some similarities but I utilized some concepts for the client grant type where this flow differs.

To understand how to implement the new classes and flow for a server here is an overflow of the flow and how a server would use them:

The server implements an authorization endpoint the client can use to request a user & device code. When this endpoint is hit the DeviceCodeGrant's create_authorization_response is called. A DeviceToken should be passed in with the expiry date configured by the server as well as a RequestValidator configured to return the verification url and polling interval.
The client displays the user code to the user and the verification url. Once user enters code which exists . The server calls DeviceCodeGrant's create_verification_response which uses the validator to check that code exists.
If it exists then the server will ask user to allow or disallow. The server calls DeviceCodeGrant's create_verification_response which will this time ask the validator to update the authorized state.
Whilst this happening the client is polling a endpoint for the token status. Each time the server will call DeviceCodeGrant's create_token_response method. The validator's validate_token_request will validate the device token is authorized and should implement all of the error codes from the RFC (including rate limiting if needed).

Once authorized this method will use the create_token method on the BearerToken to create a new Access Token, ask the validator to save it and then invalidate the old device code.

duaneking · 2019-01-24T20:12:36Z

This PR can not be included or merged if the issues are not fixed.

I'm leery of a custom login flow that doesn't cite any RFC;s being added to the lib anyway, since it's a new attack vector.

What RFC's does this implement? This seems like a custom flow and as a one-off pr for an unknown process flow with no RFC or standardization, I'm inclined to reject it anyway.

Edit: I looked at the original link and I'm not sure this is a good fit for the lib until we support JWT's fully for clients.

jcampbell05 · 2019-01-25T09:00:19Z

This PR can not be included or merged if the issues are not fixed.

Of course but I'm still working on it locally in a project to test the APIs.

I'm leery of a custom login flow that doesn't cite any RFC;s being added to the lib anyway, since it's a new attack vector.

What RFC's does this implement? This seems like a custom flow and as a one-off pr for an unknown process flow with no RFC or standardization, I'm inclined to reject it anyway.

It implements this draft flow https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13

Edit: I looked at the original link and I'm not sure this is a good fit for the lib until we support JWT's fully for clients.

This flow doesn't require JWT so not sure what the blocker is there.

duaneking · 2019-01-25T19:21:12Z

Its architectural.

If you look at the token types and the generator it looks like some test shims exist for JWT that point out the problems in the WebApp client, but they are otherwise dead code as they are only referenced in tests.

For example, grant types etc are currently assumed (and hard coded), so that architectural work will need to be done to support multiple, in order to support both this device stuff and the JWT.

jcampbell05 · 2019-01-28T10:29:22Z

Its architectural.

If you look at the token types and the generator it looks like some test shims exist for JWT that point out the problems in the WebApp client, but they are otherwise dead code as they are only referenced in tests.

For example, grant types etc are currently assumed (and hard coded), so that architectural work will need to be done to support multiple, in order to support both this device stuff and the JWT.

Okay, if there is going to be a architecture change then I'm happy to pause this PR and mark it dependent on that change. Is there an issue I can reference ?

duaneking · 2019-01-29T18:46:33Z

The change hasn't happened yet, its just something I noticed the other day so I'm thinking we should work to common goals. The grant_type for example is hard coded but for JTW you need a very different value because an assert needs to happen that the value was used.

We need to be able to support a different type based on the type of token being used; if you want to do that work as part of your PR it would help with support for both.

thedrow · 2019-08-11T14:29:01Z

FYI we're at draft 15 now.
If you still want to work on the PR, you'll have to rebase and update it.

jcampbell05 · 2019-08-12T19:10:53Z

@thedrow no worries, I will do so.

JonathanHuot · 2019-08-29T08:46:30Z

Finalized as RFC8628 : https://tools.ietf.org/html/rfc8628

jcampbell05 · 2019-08-29T14:25:09Z

I'l restart this work with the final RFC :)

thedrow · 2019-10-23T11:23:20Z

@jcampbell05 Ping?
Any change to get some progression on this PR soon or should we close it for now?

auvipy

Please rebase and let us know if you got the bandwitdh to move this forward! great job so far!

thedrow · 2020-04-22T10:04:12Z

@jcampbell05 Is that a no?
Last chance before we close this and open an issue instead.

jcampbell05 · 2020-04-22T16:01:42Z

No lets close it and open an issue - I've ran out of bandwidth at the moment but this can serve as a POC at least for anyone wanting to pick this back up

If I have time in the future then can open a new PR

auvipy · 2020-05-12T16:33:36Z

No lets close it and open an issue - I've ran out of bandwidth at the moment but this can serve as a POC at least for anyone wanting to pick this back up

If I have time in the future then can open a new PR

I will push on your branch. I will take on this :)

LiamBrenner · 2022-07-06T13:08:47Z

@auvipy Is this still being actively worked on?

auvipy · 2022-07-06T13:16:56Z

@auvipy Is this still being actively worked on?

no, need to come back to this, are you interested?

auvipy · 2023-03-24T11:33:25Z

oauthlib/oauth2/draft_ietf13/__init__.py

+for consuming and providing OAuth 2.0 IETF13 Draft.
+"""
+
+from __future__ import absolute_import, unicode_literals


Suggested change

from __future__ import absolute_import, unicode_literals

auvipy · 2023-03-24T11:33:44Z

oauthlib/oauth2/draft_ietf13/endpoints/code.py

+This module is an implementation of various logic needed
+for consuming and providing OAuth 2.0 Draft IETF 13.
+"""
+from __future__ import absolute_import, unicode_literals


Suggested change

from __future__ import absolute_import, unicode_literals

auvipy · 2023-03-24T11:34:13Z

oauthlib/oauth2/draft_ietf13/endpoints/verification.py

@@ -0,0 +1,81 @@
+# -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:34:26Z

oauthlib/oauth2/draft_ietf13/endpoints/verification.py

+This module is an implementation of various logic needed
+for consuming and providing OAuth 2.0 Draft IETF 13.
+"""
+from __future__ import absolute_import, unicode_literals


Suggested change

from __future__ import absolute_import, unicode_literals

auvipy · 2023-03-24T11:34:48Z

oauthlib/oauth2/draft_ietf13/grant_types/__init__.py

@@ -0,0 +1,8 @@
+# -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:37:53Z

oauthlib/oauth2/rfc6749/endpoints/introspect.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:38:17Z

oauthlib/oauth2/rfc6749/endpoints/pre_configured.py

@@ -1,32 +1,36 @@
 # -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:38:41Z

oauthlib/oauth2/rfc6749/endpoints/resource.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:39:19Z

tests/oauth2/draft_ietf13/grant_types/test_device_code.py

@@ -0,0 +1,174 @@
+# -*- coding: utf-8 -*-


Suggested change

# -*- coding: utf-8 -*-

auvipy · 2023-03-24T11:39:34Z

tests/oauth2/draft_ietf13/grant_types/test_device_code.py

@@ -0,0 +1,174 @@
+# -*- coding: utf-8 -*-
+from __future__ import absolute_import, unicode_literals


Suggested change

from __future__ import absolute_import, unicode_literals

James Campbell added 30 commits December 22, 2018 00:59

Initial structure for device code.

3422891

COpied authorization code class as a basis for device code.

255075d

Update link.

4d01411

Updating diagram.

474d24a

Remove non-needed step.

fac9b20

Update create_authorization_code method.

a03dc2c

Removing properties for redirect_uri.

f405c0b

Remove redirect uri from other method.

bdad7af

Update examples for authorize endpoints.

071fe90

Preparint tests for device code.

babd843

Move testsinto correct module.

8993548

Updating references.

6d0197b

Fixes imports.

9f106df

Create a common module to hold common classes.

056fc0e

Commented out error code.

3fcecf6

Use explanation from actual docs.

b43e333

Extend base grant.

06ec4c4

Basic logic for making auth code.

339f381

Adding extra fields.

521490d

Preparing for validator.

369f0b1

Preparing to handle device code genetation to a class.

328933e

Preparing a class which actually creates the tokens.

504591c

Import OAuth2Token.

d3da750

Preparing code genration code.

598f000

Implemented basic code generator.

872ce78

Split code generation for user and device.

a375054

Add verification_url property.

79264f8

Rename code to user_code.

c2ef022

Only allow token class to handle immutiable logic.

5c775cf

Get interval and verification url information to request validator.

4ac160f

James Campbell added 5 commits January 10, 2019 13:24

New verification endpoint.

bad92db

Verification Endpoint.

84b3b1a

Moving classes back into there own areas.

90c859b

Updating references.

f351c2a

Break the circular import.

aa0afca

thedrow added Feature OAuth2-Provider This impact the provider part of OAuth2 labels Aug 29, 2019

JonathanHuot mentioned this pull request Oct 18, 2019

Initial custom grant type documentation. #702

Merged

auvipy requested changes Feb 28, 2020

View reviewed changes

auvipy self-assigned this May 12, 2020

auvipy added this to the 4.0.0 milestone May 12, 2020

JonathanHuot changed the title ~~Device code~~ TODO: Provider - Device code Feb 19, 2022

jcampbell05 mentioned this pull request Mar 24, 2023

Device Code Grant Type #626

Open

auvipy requested changes Mar 24, 2023

View reviewed changes

oliamb mentioned this pull request Mar 24, 2023

Add the device authorization endpoint #844

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TODO: Provider - Device code #640

TODO: Provider - Device code #640

jcampbell05 commented Dec 28, 2018 •

edited

duaneking commented Jan 24, 2019 •

edited

jcampbell05 commented Jan 25, 2019

duaneking commented Jan 25, 2019 •

edited

jcampbell05 commented Jan 28, 2019

duaneking commented Jan 29, 2019

thedrow commented Aug 11, 2019

jcampbell05 commented Aug 12, 2019

JonathanHuot commented Aug 29, 2019

jcampbell05 commented Aug 29, 2019

thedrow commented Oct 23, 2019

auvipy left a comment

thedrow commented Apr 22, 2020

jcampbell05 commented Apr 22, 2020 •

edited

auvipy commented May 12, 2020

LiamBrenner commented Jul 6, 2022

auvipy commented Jul 6, 2022

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

auvipy Mar 24, 2023

		@@ -0,0 +1,174 @@
		# -- coding: utf-8 --
		from __future__ import absolute_import, unicode_literals

TODO: Provider - Device code #640

Are you sure you want to change the base?

TODO: Provider - Device code #640

Conversation

jcampbell05 commented Dec 28, 2018 • edited

duaneking commented Jan 24, 2019 • edited

jcampbell05 commented Jan 25, 2019

duaneking commented Jan 25, 2019 • edited

jcampbell05 commented Jan 28, 2019

duaneking commented Jan 29, 2019

thedrow commented Aug 11, 2019

jcampbell05 commented Aug 12, 2019

JonathanHuot commented Aug 29, 2019

jcampbell05 commented Aug 29, 2019

thedrow commented Oct 23, 2019

auvipy left a comment

Choose a reason for hiding this comment

thedrow commented Apr 22, 2020

jcampbell05 commented Apr 22, 2020 • edited

auvipy commented May 12, 2020

LiamBrenner commented Jul 6, 2022

auvipy commented Jul 6, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcampbell05 commented Dec 28, 2018 •

edited

duaneking commented Jan 24, 2019 •

edited

duaneking commented Jan 25, 2019 •

edited

jcampbell05 commented Apr 22, 2020 •

edited