{{ message }}
Repository navigation
feat: add manual linking APIs - #1317
Merged
Merged
Conversation
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
kangmingtay
commented
Nov 22, 2023
J0
approved these changes
Nov 22, 2023
hf
approved these changes
Nov 22, 2023
hf
left a comment
Contributor
There was a problem hiding this comment.
Would appreciate at least one test to exercise linkIdentityToUser which can be tested in isolation, no need for a whole request-response setup.
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
…otrue into km/feat-link-identity
kangmingtay
force-pushed
the
km/feat-link-identity
branch
from
November 28, 2023 08:13
05c7b27 to
3b0b550
Compare
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
hf
approved these changes
Nov 29, 2023
Contributor
|
Is it possible to test this locally? It doesn't seem as though any set of env variables or config.toml changes enable us to :( |
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 15, 2024
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
cemalkilic
pushed a commit
that referenced
this pull request
Aug 7, 2025
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
xeladotbe
pushed a commit
to xeladotbe/supabase-auth
that referenced
this pull request
Sep 27, 2025
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
fadymak
pushed a commit
that referenced
this pull request
Sep 30, 2025
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

What kind of change does this PR introduce?
GET /user/identities/authorizewhich is an endpoint to initiate the manual linking process and can only be invoked if the user is authenticatedGET /user/identities/authorizefunctions similarly toGET /authorizewhere the user needs to login to the new oauth identity in order to link the identityDetails
LinkingTargetIdis introduced in the oauth state to store the linking target user ID. This ID will be used in the callback to determine the target user to link the candidate identity used