Posts made by justing

@dan Thanks for the help, I was able to get it working.

If it helps anyone else, my problem was misunderstanding how to properly do custom login/linking. I was trying to get FusionAuth to acquire the authorization code from the third-party provider and then return it to my code, where I would call further api functions. Everything works fine now that I acquire the authorization code directly and pass it to the FusionAuth api calls.

@dan
Thank you for pointing out that client id and secret are available from the api. I missed that when I looked before.

I do not want to use the hosted login page.

Maybe this is a more direct way of asking what I want:
Can I use FusionAuth to get an authorization code from a third party OIDC provider without the user having a FusionAuth account first?

If so, it looks like I can do what I want with /api/identity-provider/login and /api/identity-provider/link. I just need to get that authorization code first.

@dan Thanks for the response.

Basically I want to do third party service authorization like described here: https://fusionauth.io/learn/expert-advice/oauth/modern-guide-to-oauth#third-party-service-authorization

The workflow for this mode looks like this:

1. A user visits TWGTL and logs into their account.
2. They click the “My Profile” link.
3. On their account page, they click the “Connect your WUPHF account” button.
4. This button takes them over to WUPHF’s OAuth server.
5. They log in to WUPHF.
6. WUPHF presents the user with the “permission grant screen” and asks if TWGTL can WUPHF on their behalf.
7. The user grants TWGTL this permission.
8. WUPHF redirects the browser back to TWGTL where it calls WUPHF’s OAuth server to get an access token.
9. TWGTL stores the access token in its database and can now call WUPHF APIs on behalf of the user. Success!

I don't have a web user interface for the user to log in at, instead it is a custom application. But I do have a web service to handle the OAuth flow so when the user click's the "Connect to third-party" button in the application it opens a browser window for them to go through the authorization process.

According to https://fusionauth.io/docs/v1/tech/apis/identity-providers/openid-connect#complete-an-openid-connect-login, I need an authorization code from the OIDC identity provider. The problem I'm stuck on is that calling fusionauth/oauth2/authorize is trying to complete the link instead of returning the authorization code.

I'm guessing the way I am trying to use the authorize endpoint is not the intended way. I was trying to use FusionAuth to acquire the authorization code from the OIDC identity provider so that I would not have to maintain my client code and secret in two places. Am I just supposed to get the authorization code myself without going through FusionAuth?

I want to allow a logged in user to link with a third-party identity provider so my app can get a token for that provider. I'm trying to use a pending link, but the problem I am running into is that FusionAuth wants the complete the pending link instead of allowing my application to complete it. Is it possible to do what I want? When I call fusionauth/oauth2/authorize I already have the user's FusionAuth ID, so I just want the pending link ID to finish the link myself.

Current setup:
I have a non-browser client application that is not using hosted login, but is instead using api/login.
I have an existing user in Fusion Auth (self hosted) with no linked accounts and registered to my application.
I created an OIDC identity provider with the link strategy of Pending Link and set Create Registration to false. No reconcile lambda.
An identity provider with the same client id/secret and endpoints works to create FusionAuth accounts when linking strategy is "Link on email" and Create Registration is true.
I have a web server that exposes endpoints for the client and makes requests to FusionAuth.

What I tried/expected:

1. Client app opens browser to mysite/authorizelink, passing the FusionAuth token returned by /api/login and an Identity Provider ID.
2. mysite calls fusionauth/oauth2/authorize with idp_hint and response type "code".
3. Browser is redirected to provider/oauth2/authorize
4. User logs in to provider & authorizes
5. Provider redirects browser to fusionauth/oauth2/callback with authorization code
6. FusionAuth redirects browser to mysite/authorizelinkcallback
7. mysite calls fusionauth/api/identity-provider/login with application ID, authorization code, redirect uri, and IdP ID.
8. If a pending link id is retrieved, mysite calls fusionauth/api/identity-provider/link with the FusionAuth user ID and pending link ID.

What happens:
Steps 1 through 5 go as expected.
After being redirected to fusionauth/oauth2/callback, instead of being redirected to mysite/authorizelinkcallback, the browser is instead redirected to fusionauth/oauth2/start-idp-link, which prompts the user to login or cancel the link request.