feat: add manual linking APIs by kangmingtay · Pull Request #1317 · supabase/auth · GitHub
Skip to content

feat: add manual linking APIs - #1317

Merged
kangmingtay merged 14 commits into
masterfrom
km/feat-link-identity
Nov 29, 2023
Merged

kangmingtay merged 14 commits into
masterfrom
km/feat-link-identity

Conversation

@kangmingtay

@kangmingtay kangmingtay commented Nov 22, 2023 •

Copy link
Copy Markdown
Member

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
// 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.

@kangmingtay
kangmingtay requested a review from a team as a code owner November 22, 2023 05:58
Comment thread internal/api/identity.go Outdated

@hf hf left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would appreciate at least one test to exercise linkIdentityToUser which can be tested in isolation, no need for a whole request-response setup.

Comment thread internal/api/api.go Outdated
Comment thread internal/api/external.go Outdated
Comment thread internal/api/external.go
Comment thread internal/api/external.go
Comment thread internal/api/identity.go Outdated
@kangmingtay
kangmingtay force-pushed the km/feat-link-identity branch from 05c7b27 to 3b0b550 Compare November 28, 2023 08:13

@hf hf left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

Comment thread internal/api/identity.go Outdated
@kangmingtay
kangmingtay merged commit 80172a1 into master Nov 29, 2023
@kangmingtay
kangmingtay deleted the km/feat-link-identity branch November 29, 2023 22:26
@github-actions

Copy link
Copy Markdown
Contributor

@mosnicholas

Copy link
Copy Markdown

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>
@johndpope

johndpope commented Dec 23, 2024 •

Copy link
Copy Markdown

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants