-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[msal-core] Update and refactor scope validation #1681
Conversation
…ed on changes to scopes validation behavior. Also remove client ID only scope error given we will no longer force clientID to be the only scope sent to request id token
…oft-authentication-library-for-js into update-scope-validation
…ing because profile scope is required to get client_info from server
…t-authentication-library-for-js into update-scope-validation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job here. Could maybe add some comments or docs around scopes, but can be done in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @Technical-Boy and @jo-arroyo!
* Update UserAgentApplication.ts refactor and extend getTokenType to remove the need for silentCall boolean and use scopes to determine return types * Update getTokenType and it's references in UserAgentApplication to correctly implement the scopes to response type mapping table from the design spec * Add newest draft of response-types doc Co-authored-by: Jo Arroyo <joliuac@gmail.com> Co-authored-by: Jo Arroyo <joarroyo@microsoft.com>
Closing in favor of going with the solution implemented in #2022. The approach and original goals of this PR were based on a slight misunderstanding of the problem, so the solution isn't appropriate. |
Description
This PR updates the way scopes are validated and dynamically generated for login requests as a primer for token request type definition behavior changes (PR #1628).
Overview
validateRequest
method inRequestUtils
that checks whether the request is of "Login" type through a boolean argument, this PR adds a separatevalidateLoginRequest
method that is called from our login APIs, and wraps thevalidateRequest
method which is called fromacquireToken
APIs.RequestUtils.validateLoginRequest
method is responsible for appendingopenid
andprofile
to the request scopes before calling the more generalvalidateRequest
method.UrlUtils.translateclientIdUsedInScope
out intoScopeSet.generateLoginScopes
in order to have that behavior under the right namespace.ScopeSet
andRequestUtils
classes.Main changes per file:
ScopeSet.ts
validateInputScopes
: SinceRequestUtils.validateRequest
doesn't need to check for!isLoginCall
anymore and the check for!scope
is carried out regardless,ScopeSet.validateInputScopes
can assume request is non-null. This means validateInputScopes now only throws in the following cases:generateLoginScopes
: SinceUrlUtils.translateclientIdUsedInScope
deals with scopes, it is moved toScopeSet
and refactored asgenerateLoginScopes
. This method is always called inRequestUtils.validateLoginRequest
for login API calls, and is called inRequestUtils.validateRequest
when any of the three recognized "login scopes" is included in the request scopes, as determined by the result of callingScopeSet.isLoginScopes
. This forces login API calls to contain 'openid' and 'profile' scopes, and allows access token requests to also make id token requests (i.e. id_token token response type). This method is written in a way that avoids adding duplicates of login scopes.isLoginScopes
: A simple new method that returns true if any of the login scopes ('openid', 'profile' or the clientId value) are included in the scopes. This method determines which non-login API acquire token calls should also have 'openid' and 'profile' scopes appended and, therefore, obtain an id token as well as an access token.ServerRequestParameters.ts
scopes
assignment into a single line that trims and converts scopes array to lowercase or sets scopes to empty array if request scopes are null.UserAgentApplication:
Replace call to
RequestUtils.validateRequest
withRequestUtils.validateLoginRequest
in login API calls, as well as update parameters in allvalidateRequest
calls given the change in the method's signature (isLoginCall
param no longer required).acquireTokenHelper
: Removescope
assignment forregisterCallback
call at the top of the method and add an updated version that simply joins the request scopes, which have already been trimmed, downcased and validated, within thethis.registerCallback
call arguments.buildIDTokenRequest
Remove client id from request, replace with a new array build from spreading whatever scopes the request already has.ClientConfigurationError.ts
client_id_input_scopes_error
since we're no longer forcing clientId as only scope.RequestUtils.ts
validateRequest
:isLoginCall
boolean parameter from method signaturevalidateLoginRequest
).validateLoginRequest
.validateLoginRequest
: New method inRequestUtils
that wrapsvalidateRequest
, only called from login APIs inUserAgentApplication
.validateRequest
to continue regular request validation.UrlUtils.ts
createNavigateUrlString
:openid
andprofile
are always added, regardless of whetherclientId
is present or notclientId
is not being removed anymore, so it is added as a scope to the request URL string (in accordance to the B2C use case whereclientId
value is a valid scope).2.
translateClientIdUsedInScope
: Method refactored out intoScopeSet.generateLoginScopes
andScopeSet.isLoginScopes
.