Yes, you can manually construct a registration URL that includes PKCE values.

1. Understanding the Registration URL with PKCE

The /oauth2/register endpoint works similarly to the /oauth2/authorize endpoint but is used for user registration. Both support PKCE.
Example URLs:

Standard Authorization URL: https://your-fusionauth-instance/oauth2/authorize? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback Registration URL (Same Structure, Different Endpoint): https://your-fusionauth-instance/oauth2/register? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback

Since PKCE is enabled, you must append PKCE parameters:

code_challenge (derived from code_verifier) code_challenge_method=S256

2. Generating PKCE Parameters

Your application must generate a code_verifier and code_challenge before redirecting to FusionAuth’s registration page.

Node.js Example:

const crypto = require('crypto'); function base64URLEncode(str) { return str.toString("base64").replace(/\+/g, "-").replace(/\//g, "_").replace(/=/g, ""); } function sha256(buffer) { return crypto.createHash("sha256").update(buffer).digest(); } function generateVerifier() { return base64URLEncode(crypto.randomBytes(32)); } function generateChallenge(verifier) { return base64URLEncode(sha256(verifier)); } // Generate PKCE values const codeVerifier = generateVerifier(); const codeChallenge = generateChallenge(codeVerifier); console.log("Code Verifier:", codeVerifier); console.log("Code Challenge:", codeChallenge);

3. Constructing the Registration URL

Once you have the code challenge, construct the registration URL as follows:

https://your-fusionauth-instance/oauth2/register? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback& code_challenge=yourGeneratedCodeChallenge& code_challenge_method=S256

4. Completing the PKCE Flow After Registration

After the user completes registration, FusionAuth will redirect them to your app with an authorization code.
Your app must then exchange this code for an access token by sending the code_verifier to /oauth2/token.

For full details on the PKCE flow, see:

Using OAuth and PKCE with FusionAuth

Summary

There’s no auto-generated PKCE registration URL, but you can manually construct one. Generate the PKCE values before redirecting users to /oauth2/register. Complete the PKCE flow by exchanging the authorization code with the code_verifier.

Yes, exchanging a refresh token for a new access token (JWT) does count as a login event in the Login report.

Events That Count as a "Login":

A login is completed using any Login API (e.g., normal login, one-time login, passwordless login, Identity Provider login, or Connector-based login). A user is created with a password (whether through self-service registration or the Registration API). A refresh token is exchanged for a new JWT. A user successfully completes a 2FA login.

For more details, refer to:
What Makes a User Active?

Hi @vinicius-alfonso !

As documented here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo we don't provide the address info, even if you pass the address scope.

Per the OpenID spec, section 5.4, it appears that supporting the address scope is optional: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

If this is important to you, please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues with details about the use case.

We are guided by our customers and community when it comes to implementation of issues. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

Hi @chrissmueller328,

You will want to review our linking strategies. When this occurs, oftentimes, this is due to custom mapping needed (you can see this in our discord doc).

https://fusionauth.io/docs/v1/tech/identity-providers/#linking-strategy-examples

The event log is another great place to look to see how your user is or is not being linked/created.

You can also look at our doc for discord as an IDP

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/discord

Hope this helps!
Josh

@falk-jaeger
I figured out where to configure the 'Forgot Password Feature. You have to set a template to the 'Forgot Password' Field in the Email settings of the Tennant.

44545473-38b0-41a8-a6ab-e581c7bd04b2-image.png

@dan

I actually got the issue resolved, I had the PKCE configured as "Not Required". After I changed that to "Required" the flow worked as expected.

Thanks.

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

The only two grants that are relevant to an interactive flow are the authorization grant, and the implicit grant.

I don’t recommend you use the implicit grant at all, so that leaves only the authorization grant.

If the authorization grant is happening, response_type will be code.

If the authorization grant is occurring due to a device grant, the user_code variable will be set.

FusionAuth does not support mapping these URLs, you may be able to accomplish that through CloudFront or some other proxy configuration.

We'd recommend a redirect.

the difference between a JWT/access token and a refresh token is that a refresh token can be revoked. Every time you present it to the Identity Provider/OAuth server, the OAuth server can check to see if the user has been banned, signed out or otherwise invalidated that token. (You can revoke a JWT, but it's a pain, typically.)

A refresh token is an engineering tradeoff. Without refresh tokens, you would have two unappetizing alternatives:

an access token that lived for a long time. In this case, if the access token is stolen, the attacker has a lot of time to access systems (or you need to have some kind of access token revocation strategy, which degrades the value of stateless access tokens). requiring the user to sign in every time the token expires. That gets old if the lifetime of the access token is minutes or hours. I even get annoyed every time Google asks me to re-sign into gmail, which only happens every week or two.

The spec requires a client to explicitly request a refresh token. With FusionAuth you have to request the offline_access scope (which is common for other auth providers, but I wasn't able to find it in the RFC), so it's a way to offer more flexibility.

@dan said in Shopify integration:

Hmmm. That's a bummer that Shopify isn't being responsive. Here's what I have found:

Can Shopify Plus acts as an Identity Service provider (physically store the users without using 3r party ISP) and allow other applications (including ours) to authenticate via SAML?

Yes, documented here: https://help.shopify.com/en/manual/shopify-plus/security/saml

This looks like this only works with Shopify users who are in your organization. (Employee time tracking, not time recording.)

Can Shopify (Plus or Non-Plus) authenticate users using Shopify accounts.

I don't know. This https://shopify.dev/tutorials/authenticate-with-oauth sure looks like a OIDC flow, but I'm not sure how it works without setting it up. Have you tried to set up an OIDC identity provider? That's what I'd do.

Dan, You right
It`s works without setting it up, Thank You

@chirag have you seen these? https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

Reviewing them and mapping your use case on to them may be helpful.

There are two “worlds”, OAuth, and API only.

API world (JSON in body, proprietary to FusionAuth):

Application > Security > Login API Settings > Generate Refresh Tokens (Generate a a refresh token when using the Login API) Application > Security > Login API Settings > Enable JWT refresh (Allow a JWT to be refreshed using the /api/jwt/refresh API)

OAuth world (form params, in body and in request, standardized):

Application > OAuth > Generate Refresh Tokens (Generate a refresh token if offline_access scope was requested) Application > OAuth > Enabled Grants > Refresh Token (Allow a JWT to be refreshed using an refresh token) (edited)

If you are living in the OAuth world, then you can disable the API access, and just use the OAuth configuration. And vice versa.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.

Thanks!

This is possible. Doing so allows you to weave passwordless into the normal OAuth flow so you can use standard OAuth libraries but not have your user enter a password.

Start the passwordless login on the server side (using the API). Get the passwordless code. Send this url to the client: [FusionAuthURL]/oauth2/passwordless/[passwordlesscode]?redirect_uri=[redirect URI]&response_type=code&client_id=[client_id]. Have the client request this url. It'll be just as if the user had authenticated via the /oauth2/authorize endpoint and the user had entered their credentials. You'll get back an authorization code which can then be exchanged for an access token/JWT.

Yes and no. Since OAuth 2.1 isn't released yet (though the working group seems to be getting pretty close) no one can "support" it yet. This is the draft specification right now: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

This blog post examines some of the changes and how FusionAuth is set up to handle them: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1#can-you-use-oauth-21-right-now

Support for wildcards in redirect URIs just landed in 1.43.

We don't recommend using these because they are against the OAuth specification (you could look at using the state parameter instead).

But we listened to the community feedback on this issue: https://github.com/FusionAuth/fusionauth-issues/issues/437 and implemented it.

It is still being documented, but you can read about it here: https://fusionauth.io/blog/2023/02/16/announcing-fusionauth-1-43#support-for-wildcards-in-redirect-urls

Hope that helps, @davidmw !

That response is essentially defined by OAuth2 / OIDC as the token response. If you want to customize it, the best solution is to use a lambda to encode additional details in the access_token (JWT) and then at the client decode that value to extract the necessary claims.

More on lambdas: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

@megeshg said in Authorize device without using /oauth2/device redirect:

we are not call /oauth/device would we need to? when in the flow would we need to do this? Dont see this in the documentation?

Hmmm. I think I must have been mistaken when I suggested that. I can't track down where I came up with that. My apologies.

I'm glad you found a solution.