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.

This seems like a case for the client credentials grant, which is unfortunately still on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/155 Not sure that would help with the rotation, though. Just like username and password approach, I don't believe the credentials grant lets you rotate creds in.

Other options: you could look into a third party api management solution (as mentioned here).

Could you use longer lived JWTs but then a webhook to revoke them, as outlined here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts ?

You can control the duration on an application by application basis (so all JWTs issued by one application have to have the same length). You could create a 'services' application that only these services would have registrations with, not sure if that would work.

In general you are going to want to use a Lambda to populate additional claims: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

This issue has some notes about Hasura in particular: https://github.com/FusionAuth/fusionauth-issues/issues/61