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.
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.
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.
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.
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.
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).
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.
If you have purchased a high availability hosting plan we can configure additional URLs for you - such as login.example.com - and then FusionAuth would be in the same domain as your own application, and you'd be able to verify the domain.
Looks like your connection to FusionAuth Forum was lost, please wait while we try to reconnect.