feat: implement RFC 8628 #3912

nsklikas · 2024-12-18T09:08:55Z

This PR is a continuation of #3851. I have created it from my own personal repo and I have invited people from Ory to contribute so that we can speed up things. I think that most of the comments in the old PR were resolved, but I can copy them to this PR if we wish to keep the discussion history.

Implements the Device Authorization Grant to enable authentication for headless machines (see https://datatracker.ietf.org/doc/html/rfc8628)

Related issue(s)

Implements RFC 8628.

This PR is based on the work done on #3252, by @supercairos and @BuzzBumbleBee. That PR was based on an older version of Hydra and was missing some features/tests.

We have prepared a spec, that describes our design and implementation. We have tried to mimic the existing logic in Hydra and not make changes that would disrupt the existing workflows

Checklist

I have read the contributing guidelines.
I have referenced an issue containing the design document if my change
introduces a new feature.
I am following the
contributing code guidelines.
I have read the security policy.
I confirm that this pull request does not address a security
vulnerability. If this pull request addresses a security vulnerability, I
confirm that I got the approval (please contact
security@ory.sh) from the maintainers to push
the changes.
I have added tests that prove my fix is effective or that my feature
works.
I have added or changed the documentation.

Further Comments

Notes:

The current implementation has been manually tested only for memory and postgres databases. The tests pass all of them.
Fosite is installed from our fork to ease testing. Once the relevant PR in fosite is merged, we will update go.mod.

Testing

To test this you need to built the hydra image:

make docker

This will create an image with the name: oryd/hydra:latest-sqlite

To run the flow you can use our UI, from https://github.com/canonical/identity-platform-login-ui/tree/hydra-device-test:

git clone git@github.com:canonical/identity-platform-login-ui.git -b hydra-device-test
cd identity-platform-login-ui/
# The image name is hard-coded in the docker-compose file
docker compose up --remove-orphans --force-recreate -d

Create a client for Hydra:

docker exec -it identity-platform-login-ui-hydra-1 hydra create client   --endpoint http://localhost:4445   --grant-type authorization_code,refresh_token,urn:ietf:params:oauth:grant-type:device_code --scope openid,offline_access,email,profile --token-endpoint-auth-method client_secret_post

Use that client to perform the device flow:

docker exec -it identity-platform-login-ui-hydra-1 hydra perform device-code --client-id <client-id> --client-secret <client-secret> -e http://localhost:4444 --scope openid,offline_access,email,profile

The user for logging in is:

username: test@example.com
password: test

aeneasr

Very nice! I'll push some minor changes from my side and left a couple of comments.

I primarily cleaned up error handling to make it standards compliant

consent/handler.go

aeneasr · 2025-01-16T11:20:29Z

consent/handler_test.go

+	require.Contains(t, result.RedirectTo, "device_verifier")
+}
+
+func TestAcceptDuplicateDeviceRequest(t *testing.T) {


Is this testing if we can accept the same device challenge twice? If so, we need two tests:

Test if we can accept the same device challenge twice and that the device verifier is valid

Test if we can accept the device challenge once, use it, then try again, and fail

I think that 1 is handled by this test

About 2, a device challenge can be used multiple times. The reason for that is that only the consent challenge ID is unique in the database. Multiple flows with the same device challenge can be persisted in the database, as long as they have a different consent challenge ID and are associated with a different user_code. I think that the same is true for the login_challenge.

Do you think that the device_challenge should be unique?

Yes, the device_challenge must be unique, otherwise we have a potential replay attack vector

aeneasr · 2025-01-16T11:20:58Z

consent/handler_test.go

+			validateResponse: func(resp *http.Response) {
+				require.EqualValues(t, http.StatusBadRequest, resp.StatusCode)
+			},
+		},


Maybe you can add a test case here where a device auth code is already used

consent/strategy_default.go

oauth2/handler.go

aeneasr · 2025-01-16T11:40:20Z

oauth2/handler.go

+	if err != nil {
+		h.r.Writer().WriteError(w, r, err)
+		return
+	}


Change this to UPDATE ... SET accepted WHER nid=... AND request_id = ? ?

Oh, I'm sorry, it appears that there are quite a lot of values being copied around here

Do you know which values need to be updated here? Is it all of them? Or just some?

I'm not sure to which line you are referring to.

Damn, looks like my comment was saved on the wrong file. I'm resolving this

aeneasr · 2025-01-16T11:41:16Z

oauth2/handler.go

+			"prompt",
+			"acr_values",
+			"id_token_hint",
+			"nonce",


This looks copy pasted - could you make this list a variable for re-use?

It's taken from https://github.com/ory/fosite/blob/master/handler/openid/flow_explicit_auth.go#L29. I will make it a variable here, should I add a comment with a link to fosite?

persistence/sql/migrations/20241609000001000000_device_flow.cockroach.up.sql

aeneasr

A few more comments, but I think we're getting quite close. Preventing replay attacks definitely needs to be addressed before merge

.schema/config.schema.json

driver/config/provider.go

persistence/sql/migrations/20241609000001000000_device_flow.cockroach.up.sql

aeneasr · 2025-01-27T10:35:02Z

persistence/sql/src/YYYYMMDD000001_device_flow/20241609000001000000_device_flow.mysql.up.sql

@@ -0,0 +1,45 @@
+CREATE TABLE IF NOT EXISTS hydra_oauth2_device_auth_codes


You can remove all files in this directory

aeneasr · 2025-01-29T09:56:02Z

Let me know when this is good for another review

nsklikas · 2025-01-29T10:09:24Z

@aeneasr sorry for the late response, everything should be good for another review now.

aeneasr · 2025-02-08T22:19:31Z

I tried performing the flow using the included CLI tooling, but it failed with this:

go run . perform device-code --endpoint  http://127.0.0.1:4444 --client-id $code_client_id --client-secret $code_client_secret
Failed to perform the device authorization request
%!(EXTRA string=oauth2: cannot fetch token: 401 Unauthorized
Response: {"error":"invalid_client","error_description":"Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The OAuth 2.0 Client supports client authentication method 'client_secret_basic', but method 'client_secret_post' was requested. You must configure the OAuth 2.0 client's 'token_endpoint_auth_method' value to accept 'client_secret_post'."})exit status 1

It appears that the error message is not properly formatted (thus the "extra" part)
The client should per default use "client_secret_basic" like the other commands

aeneasr · 2025-02-08T22:20:44Z

Or does device auth always use post form submit? From looking at the go oauth2 library it appears to be the case?

aeneasr · 2025-02-08T22:25:43Z

Would it be possible to get ory/hydra-login-consent-node#123 ready to merge so that the quickstart can be used for the device auth code flow? :)

aeneasr · 2025-02-09T16:33:02Z

I've fixed up the node PR: ory/hydra-login-consent-node#161

And made the CLI changes.

~~The node PR is still missing the device auth complete screen which we should add~~ I added the screen - please verify it's correctness

Otherwise it seems like everything is working! I was able to perform the device auth code flow end to end :)

ps: the node pr includes a pre-release of the SDK that has the device auth code flow methods included

aeneasr · 2025-02-10T10:02:44Z

One last thing we need is some docs. I was thinking a dedicated page for this grant type:

Brief introduction
End to end example
Config options
Implementation of a custom ui for the verification and success screen

@christiannwamba anything I missed?

nsklikas · 2025-02-10T10:25:18Z

Or does device auth always use post form submit? From looking at the go oauth2 library it appears to be the case?

It is a little bit weird. I think there was a discussion around this in the original PR as well, but I can't fine it right now. RFC section 3.1 says:

The client authentication requirements of Section 3.2.1 of [RFC6749]
apply to requests on this endpoint, which means that confidential
clients (those that have established client credentials) authenticate
in the same manner as when making requests to the token endpoint, and
public clients provide the "client_id" parameter to identify
themselves.

Reading this, I understand that the client must authenticate when making the device authz request. But the golang oauth2 lib does not provide client authentication in that request. There is an open issue about it golang/oauth2#685, that hasn't been addressed for quite some time. My guess is that most people will use public clients for the device flow and that's why they don't care. I think that some of the public providers don't require client authn for this request either, so I was conflicted about whether I should add it or not.

We could make the CLI work by patching the http client used to add the basic auth header, I agree that this would provide better UX. I will give it a shot.

christiannwamba · 2025-02-10T10:37:45Z

One last thing we need is some docs. I was thinking a dedicated page for this grant type:

Brief introduction

End to end example

Config options

Implementation of a custom ui for the verification and success screen

@christiannwamba anything I missed?

I think that covers it. Should go under the guides section.

aeneasr · 2025-02-10T17:09:30Z

Or does device auth always use post form submit? From looking at the go oauth2 library it appears to be the case?

It is a little bit weird. I think there was a discussion around this in the original PR as well, but I can't fine it right now. RFC section 3.1 says:

The client authentication requirements of Section 3.2.1 of [RFC6749]
apply to requests on this endpoint, which means that confidential
clients (those that have established client credentials) authenticate
in the same manner as when making requests to the token endpoint, and
public clients provide the "client_id" parameter to identify
themselves.

Reading this, I understand that the client must authenticate when making the device authz request. But the golang oauth2 lib does not provide client authentication in that request. There is an open issue about it golang/oauth2#685, that hasn't been addressed for quite some time. My guess is that most people will use public clients for the device flow and that's why they don't care. I think that some of the public providers don't require client authn for this request either, so I was conflicted about whether I should add it or not.

We could make the CLI work by patching the http client used to add the basic auth header, I agree that this would provide better UX. I will give it a shot.

It‘s fine - the device flow should actually only use public clients as end devices can‘t keep secrets. I confirmed that this works.

aeneasr · 2025-02-10T17:46:26Z

What I did:

Clean up the SQL migrations - there were a couple of NULL values that should not be null and inconsistencies between the database variants.
Change the config structure for device URLs.
Add code docs with my understanding of the business logic and simplify/clean up a bit.
Wrapped writes in performOAuth2DeviceVerificationFlow in a transaction to reduce latency.

What I found and what I believe needs to be addressed:

aeneasr · 2025-02-10T18:47:17Z

Looks like I messed up the tests - very sorry about that! I‘m currently PTO but trying to squeeze it in :)

nsklikas · 2025-02-11T09:19:20Z

Looks like I messed up the tests - very sorry about that! I‘m currently PTO but trying to squeeze it in :)

Nw, I will try to fix them

nsklikas · 2025-02-11T14:18:47Z

What I found and what I believe needs to be addressed:

1. [ ]  It does not appear to be possible to reject a device user auth code. I also noticed that the field `DeviceError` is unused (probably because the functionality is missing).

Not implementing the reject endpoint was part of the plan. I thought that it could be added at a later time if needed. The DeviceError should be used by the reject endpoint (once implemented), I will remove it for now since we are missing that functionality.

2. [ ]  Please verify that  `device_authorization_grant_id_token_lifespan` (and refresh, access) are effective with a test.

It should be tested by https://github.com/nsklikas/hydra/blob/canonical-master/oauth2/oauth2_device_code_test.go#L624

3. [ ]  `DeviceUserCodeAcceptedAt` is unused as far as I can tell. When in doubt, leave it out :)

Good catch, removed

4. [ ]  Clean of up device table is missing - we are not removing the row like we do with the oidc tables post-use and there is no clean up process. This means that in production you'll quickly run into DB growth issues. Ideally, the `hydra_oauth2_device_auth_codes` row gets removed upon use.

I thought that the tables are cleaned asynchronously by hydra janitor. Am I missing something? The janitor work was supposed to be handled on a different PR.

5. [ ]  The polling interval is purely informational and is part of the OAuth2 response. Is that understanding correct? If so, please document it as such in the config schema JSON.

That's correct, will update the schema

6. [ ]  Looking at the code I was wondering if we can somehow create a sequence where in `HandleOAuth2DeviceAuthorizationRequest` we can bypass device/login/consent verifiation? I've tried to hack around this but in my view it is not possible - please confirm:
   
   1. You can not get a login challenge without device verification, and you can't get a login verifier without a login challenge
   2. The same applies to the consent challenge - without a login verifier you can't get a consent verifier

It shouldn't be possible to do that, if you were able to get a login_verifier/consent_challenge/consent_verifier then that would mean that you would be able to do that for the common auth_code flow as well, as we are relying on the same logic/methods. Going through the code, you should not be able to get a login_challenge if you don't have a valid device_verifier.

7. [ ]  Can you please add missing cypress e2e tests for a public client performing the flow?

AFAICT the device flow is not supported by the simple-oauth2 lib, which is used in the e2e tests. I will try to implement the calls on my own.

8. [ ]  In the database, `user_code` is leaking into `request_url` in the flow table (and potentially other tables). This isn't great because the user code should really only be available to the user.

Good point, I will redact it.

9. [ ]  It took me quite some time to understand what is happening with `CreateLoginRequest` which now accepts a flow as well. As far as I understand, this is because we now create the flow (sometimes) as part of the device flow which happens before login. I'm wondering if it wouldn't be simpler to just use the existing device flow and update the state, instead of calling `CreateLoginRequest`.

Great point, I will create CreateLoginRequestFromDeviceRequest to handle this case.

10. [ ]  While we have a fallback URL for device success (`oauth2/fallbacks/device/done`), a fallback URL for device verification is missing (`oauth2/fallbacks/device`).

Right, will add it

aeneasr · 2025-02-11T15:10:00Z

Ideally we would not need the janitor (although the janitor should still try to clean the table) but instead the row is deleted when the token exchange happens:

Add janitor clean up
Clean up row after use

Without DB clean up it won't be possible to cut a release as it will cause very large DB growth very quickly

aeneasr · 2025-02-11T15:12:01Z

Regarding rejection - I'm not sure how others handle it. Is it possible to reject the device screen in other implementations?

It probably should at least programmatically be possible - for example when the device verification endpoint decides "uhhhm nope, this should not be handled by that client". But might be a bit of a fabricated use case. I would be ok not having a reject endpoint, I think.

nsklikas · 2025-02-11T15:27:56Z

Ideally we would not need the janitor (although the janitor should still try to clean the table) but instead the row is deleted when the token exchange happens:
* Add janitor clean up

* Clean up row after use
Without DB clean up it won't be possible to cut a release as it will cause very large DB growth very quickly

No problem with adding it, but can you point me to where this happens for the other oauth2 tokens as I can't really find it.

To be clear what you suggest is that instead of marking the token as used after it is accepted/rejected (soft delete), we should instead delete the row (hard delete), right?

Also keep in mind that this won't protect you from someone malicious who will spam the device_authorization endpoint.

nsklikas · 2025-02-11T15:33:58Z

Regarding rejection - I'm not sure how others handle it. Is it possible to reject the device screen in other implementations?

It probably should at least programmatically be possible - for example when the device verification endpoint decides "uhhhm nope, this should not be handled by that client". But might be a bit of a fabricated use case. I would be ok not having a reject endpoint, I think.

I think that most provider simply have a button for accepting the code, no button for rejecting it.

The [RFC}(https://datatracker.ietf.org/doc/html/rfc8628#section-3.3) says:

The authorization server prompts the end user to
identify the device authorization session by entering the "user_code"
provided by the client. The authorization server should then inform
the user about the action they are undertaking and ask them to
approve or deny the request. Once the user interaction is complete,
the server instructs the user to return to their device.

In Hydra it is possible to implement this behavior with the consent API. I am not sure if the reject endpoint will actually ever be used or not. IMHO it is a nice-to-have, but not required for an MVP.

aeneasr · 2025-02-11T15:46:46Z

Hm the spec seems to clearly indicate we need a rejection option. At this point I would like to clarify that my personal expectation is to land this feature/PR with all important aspects covered - I understand everyone has different expectations on what MVP means but for Ory Hydra it implies stability, docs, tests and spec compliance :) That‘s why this project is so popular! As I said before - we are super close and I think from the business logic aspect we have almost all bases covered :)Am 11.02.2025 um 10:34 schrieb Nikos Sklikas ***@***.***>: Regarding rejection - I'm not sure how others handle it. Is it possible to reject the device screen in other implementations? It probably should at least programmatically be possible - for example when the device verification endpoint decides "uhhhm nope, this should not be handled by that client". But might be a bit of a fabricated use case. I would be ok not having a reject endpoint, I think. I think that most provider simply have a button for accepting the code, no button for rejecting it. The [RFC}(https://datatracker.ietf.org/doc/html/rfc8628#section-3.3) says: The authorization server prompts the end user to identify the device authorization session by entering the "user_code" provided by the client. The authorization server should then inform the user about the action they are undertaking and ask them to approve or deny the request. Once the user interaction is complete, the server instructs the user to return to their device. In Hydra it is possible to implement this behavior with the consent API. I am not sure if the reject endpoint will actually ever be used or not. IMHO it is a nice-to-have, but not required for an MVP. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

aeneasr · 2025-02-11T15:46:55Z

It would get removed on token exchange - so after the consent flow is finished. You can search for DeleteOpenIDSession (or similar) in Fosite for this!Am 11.02.2025 um 10:28 schrieb Nikos Sklikas ***@***.***>: Ideally we would not need the janitor (although the janitor should still try to clean the table) but instead the row is deleted when the token exchange happens: * Add janitor clean up * Clean up row after use Without DB clean up it won't be possible to cut a release as it will cause very large DB growth very quickly No problem with adding it, but can you point me to where this happens for the other oauth2 tokens as I can't really find it. To be clear what you suggest is that instead of marking the token as used after it is accepted/rejected (soft delete), we should instead delete the row (hard delete), right? Also keep in mind that this won't protect you from someone malicious who will spam the device_authorization endpoint. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

nsklikas · 2025-02-11T16:19:22Z

It would get removed on token exchange - so after the consent flow is finished. You can search for DeleteOpenIDSession (or similar) in Fosite for this!

But that is different, user_code/device_code are similar to the auth_code. The hydra_oauth2_oidc holds information about the session. I don't see any of the oauth2 tokens being deleted when they are used (one could argue that you should keep the tokens for auditing reasons and delete them afterwards). authorization_codes and refresh_tokens stay in the database until janitor deletes them.

My question is why would you expect the database to grow that big with the device tokens and not with any of the other tokens?

nsklikas · 2025-02-11T16:28:38Z

Hm the spec seems to clearly indicate we need a rejection option. At this point I would like to clarify that my personal expectation is to land this feature/PR with all important aspects covered - I understand everyone has different expectations on what MVP means but for Ory Hydra it implies stability, docs, tests and spec compliance :) That‘s why this project is so popular! As I said before - we are super close and I think from the business logic aspect we have almost all bases covered :)

Agreed, what I meant is that IMO the current implementation is RFC compliant. approve or deny the request sounds like consent to me and that is already implemented. deny the request != reject the user_code, rejecting the user_code is the functionality that we are missing

AFAICT rejecting the user_code would be part of the consent UI or it would require a new UI screen to be implemented that would be shown before login (probably does not make much sense). We could enhance the reject consent API to also invalidate the user_code, but I am not sure I like this.

aeneasr · 2025-02-11T17:35:26Z

Hm the spec seems to clearly indicate we need a rejection option. At this point I would like to clarify that my personal expectation is to land this feature/PR with all important aspects covered - I understand everyone has different expectations on what MVP means but for Ory Hydra it implies stability, docs, tests and spec compliance :) That‘s why this project is so popular! As I said before - we are super close and I think from the business logic aspect we have almost all bases covered :)

Agreed, what I meant is that IMO the current implementation is RFC compliant. approve or deny the request sounds like consent to me and that is already implemented. deny the request != reject the user_code, rejecting the user_code is the functionality that we are missing

Fair point - the current behavior is fine then in my view!

aeneasr · 2025-02-11T17:38:26Z

It would get removed on token exchange - so after the consent flow is finished. You can search for DeleteOpenIDSession (or similar) in Fosite for this!

But that is different, user_code/device_code are similar to the auth_code. The hydra_oauth2_oidc holds information about the session. I don't see any of the oauth2 tokens being deleted when they are used (one could argue that you should keep the tokens for auditing reasons and delete them afterwards). authorization_codes and refresh_tokens stay in the database until janitor deletes them.

My question is why would you expect the database to grow that big with the device tokens and not with any of the other tokens?

The authorization code is kept around because we need it for re use detection. The oidc, pkce tables are transient tables which get cleaned up after the state is no longer required.

For the user code, do we need re use detection as well? Meaning that re using the code would invalidate the previous issued tokens? If not, we can and probably should delete it once the token exchange is completed so that the code is freed from the unique constraint. In my understanding, the user/device code is also transient and only needed to perform token exchange. Is that correct?

aeneasr · 2025-02-11T17:39:20Z

ps: we have customers with several TB of data in the individual tables so cleaning them up is definitely important :)

nsklikas · 2025-02-11T18:58:58Z

The authorization code is kept around because we need it for re use detection. The oidc, pkce tables are transient tables which get cleaned up after the state is no longer required.

For the user code, do we need re use detection as well? Meaning that re using the code would invalidate the previous issued tokens? If not, we can and probably should delete it once the token exchange is completed so that the code is freed from the unique constraint. In my understanding, the user/device code is also transient and only needed to perform token exchange. Is that correct?

Understood, yes they are transient. Given that retries are part of the flow, I think that re-use detection is not needed.

nsklikas · 2025-02-12T13:06:24Z

@aeneasr all of your comments should be resolved now except for:

cypress e2e tests
docs

AFAICT ory/hydra-login-consent-node#161 needs to be merged, in order to implement the e2e tests. Is there anything that I should do on that end?

I will try to open a PR for the docs soon.

aeneasr · 2025-02-12T13:32:23Z

@aeneasr all of your comments should be resolved now except for:

cypress e2e tests

docs

AFAICT ory/hydra-login-consent-node#161 needs to be merged, in order to implement the e2e tests. Is there anything that I should do on that end?

I will try to open a PR for the docs soon.

Just let me know if the 161 implementation is correct - then I‘ll merge that one!

nsklikas · 2025-02-13T09:32:34Z

Pushed cypress tests for the device flow. I used ory/hydra-login-consent-node#161 to run them, everything seems to work fine. Since there is no success page in that implementation, I set the success page to something in the client app to make the test implementation easier, I hope that's fine.

test/e2e/oauth2-client/src/index.js

+app.get("/oauth2/device", async (req, res) => {
+  const client = {
+    id: req.query.client_id,
+    secret: req.query.client_secret,


test/e2e/oauth2-client/src/index.js

+  headers.set(
+    "Authorization",
+    "Basic " +
+      Buffer.from(req.query.client_id + ":" + req.query.client_secret).toString(


nsklikas · 2025-02-13T13:28:14Z

The tests should be fixed when the hydra-login-consent-node PR is merged. I also opened a PR for the docs. It will need some work, but most of the required information should be there.

aeneasr · 2025-02-13T13:46:38Z

I've pushed the missing success screen, sorry about that!

nsklikas · 2025-02-13T15:56:06Z

AFAICT a new release is needed for hydra-login-consent-node as well in order for the tests to pass.

aeneasr · 2025-02-13T16:16:49Z

It uses master IIRC, so no release required

nsklikas · 2025-02-14T11:15:08Z

AFAICT it uses the latest release on the npm store (see https://github.com/ory/hydra/blob/master/test/e2e/oauth2-client/package.json#L17)

aeneasr · 2025-02-14T14:13:40Z

I see, I probably confused it with kratos CI - let’s see if this passes: https://github.com/ory/hydra-login-consent-node/releases/tag/v2.4.0-alpha.0

nsklikas · 2025-02-17T10:35:02Z

I see, I probably confused it with kratos CI - let’s see if this passes: https://github.com/ory/hydra-login-consent-node/releases/tag/v2.4.0-alpha.0

It failed, seems like it's missing a token or something

nsklikas requested review from aeneasr, hperl and alnr as code owners December 18, 2024 09:08

nsklikas mentioned this pull request Dec 18, 2024

feat: implement RFC 8628 #3851

Open

7 tasks

nsklikas force-pushed the canonical-master branch from baaef03 to 469c5e1 Compare December 18, 2024 12:13

nsklikas force-pushed the canonical-master branch from 469c5e1 to 7970287 Compare January 8, 2025 15:49

nsklikas requested a review from a team as a code owner January 8, 2025 15:49

nsklikas force-pushed the canonical-master branch from 7970287 to 8790af4 Compare January 9, 2025 09:13

aeneasr force-pushed the canonical-master branch from 8790af4 to 14cf7cd Compare January 16, 2025 10:39

aeneasr requested changes Jan 16, 2025

View reviewed changes

nsklikas force-pushed the canonical-master branch from 0a4fa13 to 2e8cf7c Compare January 24, 2025 16:47

aeneasr requested changes Jan 27, 2025

View reviewed changes

nsklikas force-pushed the canonical-master branch from 9e2e241 to d338178 Compare January 28, 2025 10:37

nsklikas requested a review from aeneasr January 29, 2025 10:08

nsklikas force-pushed the canonical-master branch from 73b187d to 9c81f0f Compare February 4, 2025 15:25

chore: install fosite from commit

2f84dae

nsklikas force-pushed the canonical-master branch from 3541e40 to d64e1c3 Compare February 11, 2025 15:40

chore: address review comments

feb95a9

fix: remove device session when used

ebfad8a

nsklikas force-pushed the canonical-master branch from d64e1c3 to ebfad8a Compare February 12, 2025 13:50

chore: add cypress tests

d55caa4

nsklikas force-pushed the canonical-master branch from cd8162e to d55caa4 Compare February 13, 2025 09:59

github-advanced-security bot found potential problems Feb 13, 2025

View reviewed changes

nsklikas mentioned this pull request Feb 13, 2025

docs: add device flow documentation ory/docs#2026

Open

6 tasks

		@@ -0,0 +1,45 @@
		CREATE TABLE IF NOT EXISTS hydra_oauth2_device_auth_codes

feat: implement RFC 8628 #3912

Are you sure you want to change the base?

feat: implement RFC 8628 #3912

Conversation

nsklikas commented Dec 18, 2024

Related issue(s)

Checklist

Further Comments

Testing

aeneasr left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aeneasr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aeneasr commented Jan 29, 2025

nsklikas commented Jan 29, 2025

aeneasr commented Feb 8, 2025

aeneasr commented Feb 8, 2025 • edited Loading

aeneasr commented Feb 8, 2025

aeneasr commented Feb 9, 2025 • edited Loading

aeneasr commented Feb 10, 2025

nsklikas commented Feb 10, 2025

christiannwamba commented Feb 10, 2025

aeneasr commented Feb 10, 2025

aeneasr commented Feb 10, 2025 • edited Loading

aeneasr commented Feb 10, 2025 • edited Loading

nsklikas commented Feb 11, 2025

nsklikas commented Feb 11, 2025

aeneasr commented Feb 11, 2025

aeneasr commented Feb 11, 2025

nsklikas commented Feb 11, 2025

nsklikas commented Feb 11, 2025

aeneasr commented Feb 11, 2025 via email

aeneasr commented Feb 11, 2025 via email

nsklikas commented Feb 11, 2025

nsklikas commented Feb 11, 2025

aeneasr commented Feb 11, 2025

aeneasr commented Feb 11, 2025

aeneasr commented Feb 11, 2025

nsklikas commented Feb 11, 2025 • edited Loading

nsklikas commented Feb 12, 2025

aeneasr commented Feb 12, 2025

nsklikas commented Feb 13, 2025

nsklikas commented Feb 13, 2025

aeneasr commented Feb 13, 2025

nsklikas commented Feb 13, 2025

aeneasr commented Feb 13, 2025

nsklikas commented Feb 14, 2025

aeneasr commented Feb 14, 2025

nsklikas commented Feb 17, 2025

aeneasr commented Feb 8, 2025 •

edited

Loading

aeneasr commented Feb 9, 2025 •

edited

Loading

aeneasr commented Feb 10, 2025 •

edited

Loading

aeneasr commented Feb 10, 2025 •

edited

Loading

nsklikas commented Feb 11, 2025 •

edited

Loading