IPublicClientApplication acquireToken takes a String[] for list of scopes while other APIs use List<String>
See original GitHub issueIs your feature request related to a problem? Please describe.
Most APIs receive a List<String>
for the oauth scopes, but IPublicClientApplication.acquireToken
still uses the old String[]
.
Describe the solution you’d like
Please make this consistent with other APIs that use List<String>
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Index (msal 2.2.3 API) - javadoc.io
Perform acquire token silent call. acquireTokenSilent(String[], IAccount, String) - Method in class com.microsoft.identity.client.
Read more >ISingleAccountPublicClientAppli...
In this mode, one account can be signed-in to the app. If the user wants to acquire a token for another account, the...
Read more >c# - Mixing graphs and customAPI scopes in single ...
You need to call AcquireToken twice when acquiring tokens silently at least. This is because an access token is only valid for one...
Read more >How to Authenticate Through Azure Active Directory to use ...
The client App will use the Access Token to call the Business Central API and get a list of environments. 1. Register the...
Read more >Business Central API - Authentication with Client ID and Secret
There are two different ways to connect to and authenticate against the APIs. 1) Use Azure Active Directory (AAD) based authentication against the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I would just deprecate the methods that dont use
*Params
builder classes rather than add more of the individual parameter methods just to address this consistency issue, but you would know better than I if there were reasons for keeping the non*Params
class ones.Thanks for the feedback @joshfriend, I’ll discuss with the team and get back to you.