Problem
/api/login and /api/passwordless/login do not accept a scope parameter, so the resulting access and refresh tokens are always issued with no scope, and a token issued by either endpoint has no path to becoming scoped without an additional exchange.
Solution
Add an optional scope parameter to /api/login and /api/passwordless/login, so the access and refresh tokens returned by either endpoint can be issued with the requested scope directly, without a separate authorization step.
Alternatives/workarounds
The current workaround is to use the scopeless access token from either login endpoint as a Bearer credential against /oauth2/authorize?scope=X, then exchange the resulting authorization code at /oauth2/token. This is functional, but requires implementing redirect interception (reading the authorization code from the Location header without following the redirect) for a fully API-driven client with no browser involved.
Additional context
This affects integrations that call /api/login or /api/passwordless/login directly instead of redirecting to FusionAuth's hosted login pages. Hosted login pages already support requesting a scope on the initial /oauth2/authorize call; direct API integrations have no equivalent option.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
Problem
/api/loginand/api/passwordless/logindo not accept ascopeparameter, so the resulting access and refresh tokens are always issued with no scope, and a token issued by either endpoint has no path to becoming scoped without an additional exchange.Solution
Add an optional
scopeparameter to/api/loginand/api/passwordless/login, so the access and refresh tokens returned by either endpoint can be issued with the requested scope directly, without a separate authorization step.Alternatives/workarounds
The current workaround is to use the scopeless access token from either login endpoint as a Bearer credential against
/oauth2/authorize?scope=X, then exchange the resulting authorization code at/oauth2/token. This is functional, but requires implementing redirect interception (reading the authorization code from theLocationheader without following the redirect) for a fully API-driven client with no browser involved.Additional context
This affects integrations that call /api/login or /api/passwordless/login directly instead of redirecting to FusionAuth's hosted login pages. Hosted login pages already support requesting a scope on the initial /oauth2/authorize call; direct API integrations have no equivalent option.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.