Device Authorization Grant: RFC 8628

[lukestoward]

trafficstars

Hi!

We (myself and my colleague) are evaluating Hydra for a current project we are working on in our organisation. But we would like to extend it by adding the Device Authorization Grant flow and as such, would like to start a discussion on what components need to be changed in order to potentially contribute to the project and open a PR that includes this flow into Hydra. (This proposal may obsolete https://github.com/ory/hydra/issues/1553)

Let me give you a bit of the use case of why we are looking at that flow.

We have a range devices that either do not, or may not, have a system browser installed, in which we would like to access a user's identity and profile information. Due to the lack of a browser on said devices, we are unable to adopt the Authorization Code Grant. In addition, those devices are often input constrained, controlled by RCU (Remote Control Units) and having to input a username/password becomes less than ideal from a usability perspective. Device Authorization Grant provides a solution to this problem. It enables a user of browserless/input-constrained device to authenticate themselves on a second, more capable device (mobile/tablet/PC), "linking" the first device via a user code, to that authenticated user. The first "linked" device, can then request access, id and refresh tokens about that authenticated user.

Device Authorisation Request To enable a device to firstly make a device authorisation request (rfc8628 section-3.1), a new endpoint would need to be exposed by Hydra on the public client. Hydra would then generate a device_code and user_code, associating this session data to the client indicated in the request. The verification_uri would be that of the configured login provider (such as ORY Kratos). Hydra would provide this information as a response to the device (rfc8628 section-3.2).

User Interaction A device would then present the user_code and verification_url to the user, instructing them to visit the URL, on a secondary device, and enter the code. (rfc8628 section-3.3)

Device Access Token Request Whilst displaying the details to the user, the device would periodically make requests to the Hydra token endpoint, explicitly providing a grant_type of urn:ietf:params:oauth:grant-type:device_code, including the device_code, retrieved in the initial device auth request, along with the same client_id used in the initial device auth request. Hydra's token endpoint logic would need to be modified to accept this new "type" of request, along with implementing the logic to check if the device has been authorised by a user. Finally, the new device access token responses would need to be supported (rfc8628 section-3.5).

Implementing the User Interface Similarly to the process of implementing the login, consent and logout interfaces, we would need to define the flow to support the implementation of the "device linking" UI. This UI being that of which the user enters the user_code presented to them. Unlike the authorization code grant, we cannot rely on Hydra to use browser redirection, to redirect the user to this device linking endpoint, with the inclusion of some challenge identifier appended to the query string. We also would like to preserve the existing login, consent accept/reject flows. Therefore we propose the following flow to be handled by a login provider implementation:

Device Linking -> Login -> Consent

Sequence diagram

* "Consent" omitted for brevity * "User authentication" simplified for brevity

To support the prosed flow in the sequence diagram above, it would require a new Hydra Admin API to validate the user code provided. If valid, this endpoint could (optionally?) return a login challenge, which would enable the login provider to perform user authentication, accept/reject the login request and accept/reject the consent request in the same way as defined today. However, Hydra would need to know how to acknowledge the completion of the Device Authorization Grant, thus enabling the device (which would be polling the token endpoint) to receive the access_token and id_token etc.

In addition, the existing responses of the accept/reject login request and accept/reject consent request include a redirect_to value. In the context of Device Authorization Grant, there would be no need to redirect the user after authentication and consent have been completed. Therefore, to ensure backwards compatibility, we propose that Hydra have a configurable "device auth complete redirect" property, that would be provided in the response to the previously mentioned requests. This could be a static page implemented by the login provider that confirms the device linking has been completed. Or, it could be ignored by the login provider completely.

Open Questions We understand that in order to implement these proposed changes we would have to modify the fosite SDK, to include a new Device Authorization handler, factory, code generation strategies, request/response types etc. Along with changes to Hydra to implement those handlers, data store, strategies etc. However, there is still a lot of unknowns about the scope of changes involved.

• Can we implement Device Authorization Grant with Hydra, independently of Kratos and other ORY products?
• Does the proposed changes outlined above provide enough clarity on how an implementation would be carried out and utilised?
• Do you see any potential issues with the approach proposed?
• Are you able to propose any alternatives to how this might be implemented?

Thanks 😃

[aeneasr]

Thank you for the detailed explanation - we definitely want to support the device auth grant type! The two additions - endpoint and new grant type - will indeed have to be implemented in fosite and we'd be more than happy to help you along the way, if you need it.

Regarding the UI flow I would need to read more about the spec first. But I generally think this is easily possible to add and also something we want to add.

So my idea would be to start with the implementation in fosite, adding support for the new endpoint and also the new grant type, and then work on the stuff here. I also think that this work here would benefit from another thing that we are planning which is to make the login/consent data model easier internally. This would probably be ready in time for this PR!

[lukestoward]

Ok thanks @aeneasr, I will start by taking a look at the changes in fosite.

[fjvierap]

Hi @lukestoward @aeneasr thanks for the great explanation about what needs to be done for support authorization grant flow. In my project we ara also using hydra and we need that feature so we plan to start the adjustments in fositie and hydra in the next weeks. Our draft road map for it will be:

• Adjust fosite to add device authorization grant flow handler, factory, code generation strategies, request/response types etc
• Adjust hydra to implement an endpoint for Device Authorization Request, where device_code and user_code will be generated and stored in database.
• Adjust token hander to accept urn:ietf:params:oauth:grant-type:device_code grant type, device_code as parameter and access_denied, expired_token, slow_down and authorization_pending as error responses
• Add a new endpoint to admin api to verify user code and return a login challenge. Any idea about the url for this new endpoint POST user_code?
• Adjust client definition for having some device_grant_login_redirect_uri... and adjust hydra to return this value after accepting consent request... (To display sone success page as we will not have redirect uri for this scenario)

Overall does it make sense to you or do see something missing?

[lukestoward]

Hi @fjvierap, I am actively working on the changes to support this flow in both fosite and Hydra. Obviously, I don't want to discourage you from implementing these changes yourself, however, this might be an opportunity to work on/review this change collaboratively. I am new to the Hydra code base and am still building my mental model of how it functions internally. I'm not sure if you have any existing experience with the code base already? Either way, you could implement the code changes and we could review this together at a future time if you'd like, since we're both looking to achieve the same result. 😄

[fjvierap]

@lukestoward Absolutely it is a great opportunity to collaborate and contribute to hydra together. :) We have done some changes in hydra and some other repos around it so we have not much, but some experience in the code base... So of the changes we did are merged already, some other under review and other are in our internal repos as there are good reasons for hydra to do not include then into their codebase but we need them in our project temporally for how we integrate with other parties... :( Due to the last point, unfortunately, we are not too fast/agile contributing to this project as first we introduce our changes in our internal repositories and once it is working we create PR to github.

For sure I will include you in all the discussions and review we will have about this topic and very happy to help or review the progress you do in the same

[tacurran]

@lukestoward @fjvierap perhaps we can set up some time to give you an orientation the the Hydra code base? Please let me know if that would be helpful.

[lukestoward]

@tacurran yes this would be very helpful. Happy to coordinate this via the Ory Community Slack if that's easier?

[fjvierap]

@tacurran that would be great!

[lukestoward]

Regarding the implementation, I've encountered a design issue with how we could store the device_code and user_code values that I would like to open up for discussion. Fosite appears to operate the storage interfaces around a signature of some value and the Requester interface. As a result, I believe this would mean we would need to store the two codes individually. In Hydra's SQL store for example, this could be two tables, one for the device_code and one for the user_code. My issue is around the primary key being the signature of the generated value, which in the case of device_code should be generated with sufficient entropy, reducing the risk of any uniqueness clash. However, this isn't true for the user_code which, being user-facing, would need to be simple, perhaps a 6 character alphanumeric code. A signature of such a value doesn't make for a very reliable primary key, particularly if generated randomly.

Therefore, I don't think this is the right approach. Is there a better way to store this information, perhaps a single table that stores both code values? I believe this would require a deviation from the existing storage interface approach, but this may be necessary. Any suggestions would be great! 😄

[fjvierap]

I also think it is better to have device_code and user_code in the same table. What I don't understand is why it is a deviation from the existing storage interface approach? :) At the end the request model represent a single request it where we can determine whet to use an ID(Pk). int this case we can have the device_code as we can set to a uuid for instance. And having an extra unique column for user_code

[lukestoward]

int this case we can have the device_code as we can set to a uuid for instance. And having an extra unique column for user_code

Yes this makes sense. I believe to enable this we'd have to add a slightly different storage interface. If you look in fosite, the Create* AuthorizeCodeSession, AccessTokenSession, RefreshTokenSession etc. all have a function signature that expects a signature and a request, which means they support only a single identifier, which is used as the primary key by Hydra. This appears to me that in Hydra, the SQL persister can generalise these different session types to work with the OAuth2RequestSQL struct type, and persist to the DB with the same schema.

To support what we're suggesting (both codes in the same table), we would have to have an extra parameter in fosite on a new CreateDeviceAuthoriseCodeSession function to support passing of both codes, plus the request. This would also mean that in Hydra, we'd have to create new persistence logic that was slightly different for mapping to a different OAuth2RequestSQL type. Now, I don't believe this a 'big deal', I'd just like to review a number of possible options before committing to any particular path.

[dadrus]

Hello everybody. @lukestoward: Thank you also from my side for the great explanation. FMPOV there are some things missing. Or I just oversee these in the discussion above. Let me recap a bit. The rfc8628 basically talks about three phases: (1) Client (device) requesting the access, (2) User granting the access and (3) Client receiving the access token.

The discussion held so far is more about (2). What I miss so far is how (1) should be handled. Given the following interaction between the client and the auth server:

Client --(scope, client_id)--> Auth Server Auth Server --(device_code, user_code, verification_uri, verification_uri_complete, expires_in, interval) --> Client

I would like to talk about verification_uri and verification_uri_complete first, which actually brings us directly to (2). @lukestoward: You suggestion is to let this end point be served by the login provider, which would then forward the user_code to hydra, probably via a specific admin end point. I'm not sure, this is the proper way to go. My reasoning is that, this way there are no authorization mechanisms in place, which hydra could make use of to ensure, the entity sending this request has indeed authenticated the user. So if, e.g. by accident the aforesaid endpoint has been made publicly available, the entirely authentication process can be bypassed. One mitigation approach would be to let hydra implement the corresponding verification_uri and verification_uri_complete endpoints. The second would require an Authorization header with an access token (the same way the user info end point works). If the Authorization header is not present, hydra would do a redirect to the login provider. The first, would always do a redirect to the login provider, as input from the user (the user_code) is required.

Having said that, here my further thoughts about (2): If a redirect happens like I've written above, the login provider would have to render a page to let the user enter the user_code. The interaction with hydra can then happen using the same patterns as already in use: hydra redirects with a challenge and the login provider makes use of it. So there is no way to bypass anything. The rest of the interaction goes as we know it today.

Let me now come back to the verification_uri_complete end point as described above. If we take a holistic approach, we'll basically enter the following situation: The user will have to interact actually with two clients. One is the device and the other is the one is either an authentication proxy in front of some kind of a web services, or a service which implements the oidc client capabilities (the web-client). And this means we'll have the following two scenarios:

1. The user is not yet authenticated to the web-client. If the user now enters the value of verification_uri_complete, the web-client, which can be put in front of hydra will not have the required Authorization header, so hydra will start the flow described above.
2. The user is already authenticated to the web-client. If the user now enters the value of verification_uri_complete, the web-client, which can be put in front of hydra will have the required Authorization header, so hydra knows, who the user is, can link the user_code to the subject. The only thing, which is then remaining is the consent management for the device client.

What do you think?

[lukestoward]

Hi @dadrus, I have made some progress on how part 2, as you've labelled, could function. I'll elaborate on my thoughts before I respond to your points above.

For the existing login and consent flows, where a login provider must communicate with the Hydra admin API to Accept/Reject a login/consent request, Hydra will respond with a redirect_to URL that instructs the login provider to redirect the user back to Hydra's /auth endpoint, with an added verifier on the query string so that Hydra can lookup the state of the login/consent request and treat it as being 'handled'. I purpose we follow this approach for the Device Auth Grant flow, where the end user is instructed to a visit the verification_url (e.g. my-login-provider.com/link) which renders the "enter your code" UI. This code is posted to the login providers backend which is then sent to a Hydra admin endpoint /verify-usercode, where Hydra then checks the user code is valid (unused, not expired etc.) and creates a handled_link_request entry, returning a redirect_to URL that instructs the login provider to redirect the user back to Hydra via the URL (e.g. /oauth2/device/code?link_verifier=xyz. Hydra then checks for authentication, redirecting the user back be authenticated if needed, just like how the existing login & consent flows operate. Hydra would keep track of the usercode, authentication and consent state and their relationship.

After consent has been given, and part 2 concludes. Then part 3, the client being granted or denied an access token etc. will proceed. Hopefully this is clear. The main issue i've faced so far is integrating the additional device-linking on top of the existing user auth and consent in such a way that I can reuse all of the same flow, since this has been battle tested for flows such as the Authentication Code Flow etc.

Now, to respond to your suggestions above.

this way there are no authorization mechanisms in place, which hydra could make use of to ensure, the entity sending this request has indeed authenticated the user. So if, e.g. by accident the aforesaid endpoint has been made publicly available, the entirely authentication process can be bypassed.

The Hydra Admin API doesn't require authentication for Get/Accept/Reject Login/Consent requests due to the nature of the admin API not being publicly exposed. Should this be misconfigured and exposed, then you have bigger problems to worry about... Therefore, a new Admin endpoint to /verify-usercode should not be any more vulnerable that the other endpoints.

One mitigation approach would be to let hydra implement the corresponding verification_uri and verification_uri_complete endpoints.

I think I understand what you're suggesting. The verification_uri points to a Hydra endpoint, which will redirect the user to the login providers "enter code UI", passing a challenge. Said challenge can then be used to communicate with Hydra to check that this "linking" attempt is valid? Or, the login provider communicates with Hydra to /verify-usercode passing the usercode and the challenge so that we can have more assurance that this request attempt is legitimate?

One problem I see with this is the complexity of the verification_uri. This is expected to be a user-facing URL and should be short and easy to manually type into a second devices address bar. Of course, a client could show a QR code, but this isn't guaranteed. Hydra would have to ensure it's host+path are user-friendly, which it probably wouldn't be in most cases. The only other downside I can think of is that this introduces yet another redirect.

Let me now come back to the verification_uri_complete

Unfortunately, I don't fully understand your final section regarding verification_uri_complete, so I can't comment.

[natsuo]

Random observation (or feature request?) when the user is linking/claiming a new device code:

When entering thr usercode, the device should be able to offer some additional information, like an IP-address (or location) and some identifying information about the device. This could be an user agent string, a device name (Apple TV - Living Room, Samsung Smart TV, raspberry pi 4). That way the user can confirm that this is indeed the product they are trying to add. Useful if they are adding multiple devices, or to ensure that they aren't claiming the wrong code.

The information should/could be sent along with their initial request (from which a usercode is returned).

[lukestoward]

Hi @natsuo, do you mean we would capture information about the client device at the point it makes the initial device authorisation request, to obtain a device code and user code? Then subsequently show this information to the user after they have provided the user code? The former wouldn't follow the RFC specification, as that clearly outlines what properties should be provided, although I guess it's possible to infer some information from the user-agent header. However, user-agents are generally a mishmash of values that can't be reliably interpreted. You wouldn't want to present the raw value to the user as it's not user-friendly at all.

I think the act of labelling a device that becomes associated with a user isn't really what this flow is about. Instead it's more about a temporary association so that a particular device can be authorised on behalf of a user who authenticates themselves on a different device. Once that 'linking' has been completed, the device code and user code become useless. Therefore, I'm not sure what value this would add. Happy to potentially explore this idea more, but I'm conscious of the scope of this initial integration as it's already quite complicated 😅 , so it might be better as a feature request later on.

[natsuo]

Upon further thought, the service I was thinking of a service I saw had a second screen. After claiming/linking the usercode you could set some additional configuration for the device. Like naming it, grouping it, colors and whatnot.

The page had a device location (based on the device's IP address), like "Codesville, FL, USA" or something like that. But that could obviously be handled through a call to the service's API.

Anyway. You can safely ignore the feature request. 😊

[dadrus]

@lukestoward

Then part 3, the client being granted or denied an access token etc. will proceed. Hopefully this is clear.

This is clear ;)

One problem I see with this is the complexity of the verification_uri. This is expected to be a user-facing URL and should be short and easy to manually type into a second devices address bar. Of course, a client could show a QR code, but this isn't guaranteed. Hydra would have to ensure it's host+path are user-friendly, which it probably wouldn't be in most cases. The only other downside I can think of is that this introduces yet another redirect.

Yes, this URL is a user facing one and should be short, but I don't think it should be addressed by hydra/login-provider. There are many solutions in the wild, offering "url shortening" services, which the device can use to shorten the URL received from hydra before presenting it together with the user_code to the user. Or, as you said, make use of verification_uri_complete and render it as a QR code, or again use an url shortening service and display that url.

There are basically two ways of how the user can submit the user_code:

1. The device displays the verification_uri as well as the user_code. The user has to navigate to that Url, which renders the required form, so the user have to enter the user_code and submit it.
2. The device displays the verification_uri_complete (which has the user_code included, e.g. as a query parameter). So the user only has to enter this Url into the browser. Alternatively the verification_uri_complete can also be embedded into a QR or shortened via a service, as written above and then displayed to the user. The end result is the same: An HTTP GET request to the Url, where the user doesn't have to enter the user_code.

I think I understand what you're suggesting. The verification_uri points to a Hydra endpoint, which will redirect the user to the login providers "enter code UI", passing a challenge. Said challenge can then be used to communicate with Hydra to check that this "linking" attempt is valid? Or, the login provider communicates with Hydra to /verify-usercode passing the usercode and the challenge so that we can have more assurance that this request attempt is legitimate?

Yes, I was talking about having more assurance, that this request attempt is legitimate.

I personally see two approaches here, which I tried to sketch in my post above:

1. Hydra orchestrates the flow to let the user enter the code

This corresponds with how you said, you understand, what I've written.

@strartuml

participant "User" as U
participant "Browser" as UA
participant "Hydra" as H
participant "Login Provider" as LP

==== If the device displays the verification_uri and user_code ====
U -> UA: Enter Url displayed by the Device
UA -> H: GET Url displayed by the Device
H -> H: Generate challenge (and do whatever else is needed)
H --> UA: redirect to login provider (Location: /loginprovider/device?device_challenge=....)
UA -> LP: GET  /loginprovider/device?device_challenge=....
LP -> H: Retrieve data from hydra associated with the received challenge
H --> LP: data
note right: The login provider can do some further business case specific checks here 
LP --> UA: HTML with form to enter user_code and challenge in a hidden field
UA --> U: Render HTML page
U -> UA: Enter user_code and submit
UA -> LP: POST /loginprovider/user_input, Body: user_code, challenge
LP -> H: AcceptDeviceLinkin(user_code, challange)
H -> H: find the record related to the device request, check user_code, etc
H --> LP: ok, next redirect (to the regular login flow)
note right: ... which instead of using the regular consent flow, would include the device consent flow.

==== If the device displays the verification_uri_complete ====
U -> UA: Enter Url displayed by the Device
UA -> H: GET Url displayed by the Device
note right: No way to verify the legitimacy of the request
H -> H: find the record related to the device request, check user_code, etc
H --> UA: redirect to the regular login flow
note right: ... which instead of using the regular consent flow, would include the device consent flow.

@enduml

In a nutshell: If the the loginprovider is involved, it would first check with hydra if the linking attempt is valid and, after receiving the code, entered by the user, pass both, the challenge and the usercode to hydra, which would then respond with a redirect to the known hydra login flow.

2. Hydra doesn't care about how the code is entered by the user. It implements an endpoint to which the user_code can be send via POST or GET. This endpoint is however protected by a bearer token, like the user info endpoint. This way hydra can always ensure the request is legitimate.

This relates to your comment

Unfortunately, I don't fully understand your final section regarding verification_uri_complete, so I can't comment.

For this to work, there is a need to configure a Url, or Url template in hydra to be displayed to the user in step (1).

In sense of deployment it would look like this:

                     +-------------------+         +--------------+           +--------------+
                     |                   |         |              |           |              |
 User   ------------>| User Code         +-------->|  Auth-Proxy  +---------->|              |
                     | Reception Service |         |              |           |    Hydra     |
                     |                   |         |              |           |              |
                     +-------------------+         +--------------+           +--------------+

The User Code Reception Service is the service responsible for taking the user input irrespective of whether the device displayed a verification_uri and a user code, or a verification_uri_complete. It will then submit it to hydra via a redirect. Since hydra would expect a Bearer Token, we put an "Auth-Proxy" (like oathkeeper, lua-resty-openidc, any type of api gateway, etc) in front of hydras "user_code" end point, which would start the authorization code grant flow and authenticate the user as we know that and finally forward the request to hydra. Hydra would find the record related to the device request, check user_code, link the subject (user) to the record etc and start the device consent flow (login flow is skipped as the user is already authenticated).

Since the device would usually :) communicate with some services, requiring an access token. And the same services usually offer their functionality as web services (something, the user will use via a borwser), requiring user authentication as well, a typical deployment scenario could look like this:

                     +-------------------+         +--------------+           +--------------+
                     |                   |         |              |           |              |
 User   ------------>| User Code         +-------->|  Auth-Proxy  +---------->|              |
                     | Reception Service |         |              |           |    Hydra     |
    |                |                   |         |              |           |              |
    |                +-------------------+         +--------------+           +--------------+
    |                                                                                ^
    |                                                                                |
    |                                                                                |
    |                                                     +--------------------------+
    v                                                     |
+----------+                                       +------+-------+           +--------------+
|          |                                       |              |           |              |
| Device   +-------------------------------------> |  Auth-Proxy  +---------->|              |
|          |                                       |              |           | Some Service |
|          |                                       |              |           |              |
+----------+                                       +--------------+           +--------------+

The Auth-Proxies could be just the same instance, or share required key material. From the user point of view both, the "User Reception Service", as well as the "Some Service" would be "same" system, served from the same domain. So if the user was already logged in (e.g. there is a cookie/session/whatever created by the Auth-Proxy), the Auth-Proxy would just use the existing access token and forward the request from User Reception Service to hydra, which will then only start the device consent flow.

This approach is definitely more complex, but is more secure and is open to different integration options. E.g. one could put the "User Code Reception Service" behind the Auth-Proxy, which would turn around the sequence: If the user is not yet authenticated, it would have to authenticate first, before being able to enter the code. Another option would be to have the "User Code Reception Service" as part of an App, and alike

I hope this explanation is better ;)

[lukestoward]

Thanks providing the sequence diagram, it definitely helps visualise what you're purposing with the additional Hydra challenge for the submission of the user code.

We know that a login/consent request challenge value is passed to the login provider for the purposes of retrieving the login/consent request information from Hydra. This challenge is an ID, which also acts as simple security mechanism to prevent unsolicited requests from malicious actors that haven't first come from Hydra. I wonder if this actually helps us in the case of the user code. If the verification_uri returned by Hydra, points to a Hydra endpoint, it wouldn't contain anything that could identify the client, such a client_id etc. since this is not what the spec defines. Therefore, a malicious actor could hit this verification_uri, get redirected with a challenge and submit any user_code repeatedly, since the challenge would be valid and perhaps a guess on the user_code would be valid. We can't associate a challenge with a user_code as the verfication_uri wouldn't contain any state that would allow us to associate them. This makes me question whether having this challenge actually offers us any additional benefit?

As for the points around the reception service and auth proxy, I worry it's far more complex, and in my head the added complexity doesn't justify the potential benefit. But I will try and find some time to digest this more, since it's a very interesting suggestion. Thanks 😄

[dadrus]

You're very welcome 😉

This makes me question whether having this challenge actually offers us any additional benefit?

The idea was to reuse the patterns already implemented by hydra for all flows. But in principle I agree with you.

My attention is more on the second scenario, as it IMHO , as I've written above, offers much more flexibility. In addition to what I've written above, imagine your device should work with an app. So when the customer goes through the onboarding, you would like to offer as seemless user experience as possible. We for example would like to embed additional stuff into the qr code. So when the user scans ist, the mobile OS would determine, whether the app is already installed, if not, it will navigate the user to the app store, let it download the app and launch the app with the parameter embedded into the qr code. This can easily be achieved with custom uri schema. The qr code could contain further information from the device, which the app could make use of. It could then launch the registration or whatever flow and then submit the received code to hydra to start the device consent. Since the app would already have the access token, it would then talk to other services to make use of additional information embedded by the device into the qr code. I'm not saying this is not possible with the other approach. It just feels more complex for such scenarios as it would result in two login flows executed by hydra (one for the device and one for the app) on the same user touch point (here on the app) and depending on how the login provider is integrated with the actual idenity management solution, this integration might become more complex, or even disturb the user by asking it to login two times, which cannot happen with the second approach. And this issue is actually not related to the type of the client - mobile app, or Web. This is my justification 😉

[dadrus]

@aeneasr: It would be great if you could show more involvement ;) here. We urgently need support for the Device Authorization Code Flow. I sketched the preferred implementation approach from our side (incl. @fjvierap), but this ticket is unfortunately stale for already 3 weeks as there is no feedback. We can for sure open a PR which will implement the aforesaid approach. We would however like to avoid such efforts, if the community doesn't see this approach as the way to go.

[aeneasr]

Hello, we had a call two weeks back with someone from BBC uView and laid out a plan for implementation. Unfortunately I don’t know the GitHub handle of that person. While we didn’t discuss this here in the issue there is a clear plan for implementation. But I don’t know the current state of the implementation.

[lukestoward]

@aeneasr this was with me 😄, and just to clarify this work/investigation is being carried out by me on behalf of YouView. I have made some progress on the implementation, not ready for PR yet though. I’ve had changing work priorities so progress has been slower than I’d like.

[dadrus]

@aeneasr, @lukestoward: Thank you for this information. But what is the plan? In our (@lukestoward) last "discussion" (see above), you wanted to digest on "my" proposal. The issues I (my team) sees with the initial proposal are already written above.

[lukestoward]

@dadrus the discussion I had with aeneasr and others from the ORY team several weeks ago centred on the original proposal documented at the top. Given the unanticipated complexity of adding support for this flow in its simplest form, I haven't extended this based on your proposal. I'd rather open a PR in the future with an MVP of sorts, and open up the approach for critique then. Of course you're welcome to do the same thing 😄

[alkiko]

Hi @lukestoward , We're looking to achieve something similar with the oauth2 Device Authorization Grant and @vinckr, @tacurran and @aeneasr suggested having a look at your work. Do you have some of the thoughts from this thread implemented that we can test, review or in any way contribute to? 😊

[lukestoward]

Hi @alkiko, unfortunately I have been unable to progress this due to a change in priorities at work. I managed to get an early WIP working, but had to stop developing due to a change in priorities. I hope to pick this up again fairly soon.

[alkiko]

I see @lukestoward. Would you mind sharing that WIP so we can test it and perhaps contribute to it? Would be a shame to have to start all over :)

[lukestoward]

@alkiko I will see if I can find some time to tidy up my fork and push that. I'll let know if/when I can do it, cheers 😄

[alkiko]

Sounds awesome @lukestoward! 😄

[alkiko]

Any news on this @lukestoward? :)