AzureAD / MSAL.PS

MIT License
159 stars 29 forks source link

IntegratedWindowsAuth example? #55

Closed Denver80211 closed 2 years ago

Denver80211 commented 2 years ago

New to oauth, hope I'm asking the question correctly. I feel like I'm really close but... I registered the app in azure, and when I get a token using this code:

$scope = @("https://outlook.office365.com/.default") $msalParams = @{ ClientId = $azureClientId TenantId = $azureTenantId Scopes = $scope RedirectUri = "https://login.microsoftonline.com/common/oauth2/nativeclient" } $token = Get-MsalToken @msalParams

I'm prompted to login with an account that has access to the Exchange mailbox I'm working on. The generated token works!! It comes back with all the assigned scopes, and I figured out how to refresh the token with -silent. Amazing!!

I would really like to avoid the login prompt, use the "currently logged in user" (Running as a service account) When I try with client secret, the token I get back doesn't have the scopes or IDToken properties, etc. And that token doesn't get me to the resources I need in EWS.

I've been searching for examples but I can't find anything about how to either pass credentials to get-msalToken as a variable or somehow inherit the "windows login session token" (I'm making that term up) for the currently logged in user. I think I would use IntegratedWindowsAuth property but I don't know what I hand that property or what other fields need to be used. Can anyone help or point me to a simple example? Perhaps I need to change a property on the azure app registration or....

Thanks!! Fred

jazuntee commented 2 years ago

By not including switches like -Interactive, -IntegratedWindowsAuth, -Silent, etc., Get-MsalToken will automatically try silent first, then Integrated Windows Auth, and finally interactive if all else fails. If you want to control it manually you can add those switches and fallback yourself. However, for authentications that must be done silently, I would recommend creating a confidential client in AAD and authenticate has the service principal itself using a ClientSecret or ClientCertificate.

Denver80211 commented 2 years ago

Thanks for the reply. Perhaps I'm missing something (forgive me I'm new to oauth so processes are not clear) What I'm unclear about here is "creating a confidnetial client in AAD" -I did create a ClientSecret. But when I use client secret, I don't get the scopes back in the token. When I try to feed the scopes to get-msaltoken, it complains they are not correct. I try to follow suggestion putting /.default on the scope url, etc but, nothing works. I even hand it back the scopes that come down when I login. nadda, The token I get using client secret looks entirely different.. smaller, fewer properties. -when I login interactively, the scopes just come down with the token. I'm sure I'm missing a key point here but, all the guides I've found seeem to assume I know the details of what I'm asking for. Hard to be a newbie! Edit: when I add -IntegratedWindowsAuth to the switch properties, the error complains that I either have missing or wrong switches in the command. I don't see an example stating what the required switches should be when leveraging -IntegratedWindowsAuth

Denver80211 commented 2 years ago

The only scope that works: $scope = @("https://outlook.office365.com/.default") Scopes from an interactive login on the token: https://outlook.office365.com/EWS.AccessAsUser.All, https://outlook.office365.com/User.Read, https://outlook.office365.com/.default I feed those to the get-MSALtoken as an array... it doesn't like em. Add /.default to the end, etc as the error suggests.. no good. But, since they come down without me specifying them, I would -hope- the same would happen with a non interactive login?
I feel so close, yet so far

Denver80211 commented 2 years ago

When looking at the command syntax structures, the only one that has the IntegratedWindowsAuth switch doesn't have clientsecret or cert in the parameters list. When I try to provide them, I get error: "Get-MsalToken: Parameter set cannot be resolved using the specified named parameters. One or more parameters issued cannot be used together or an insufficient number of parameters were provided"

So my original question was, how to get a token using current login account and I assume secret or cert? Sorry I know I must be asking this wrong... I get excited that I get a working token but can't make the leap to the next step. I looked up creating a confidential client in AAD and I -think- it's ok in azure. I have the client secret value, not ID and it's in the form of a secure string. Can't figure out where I'm missing something.

Get-MsalToken [-ClientId] <String> [-RedirectUri <Uri>] [-AzureCloudInstance ] [-TenantId <String>] [-Authority <Uri>] -IntegratedWindowsAuth  [-Scopes <String[]>] [-LoginHint <String>] [-CorrelationId <Guid>] [-ExtraQueryParameters <Hashtable>] [-ProofOfPossession <HttpRequestMessage>] [-Timeout <TimeSpan>] [<CommonParameters>]