On last April, Rene de la motte and I had a nice Teams call about my talk on PowerShell User
@AtholyMardies legt los mit OAuth2.0 und #PowerShell pic.twitter.com/6ydArdzK4X
— Hamburg PowerShell User Group (@hhpsug) 31. Januar 2019
Group Hamburg and how to use PowerShell to authenticate against Azure AD and make use of Microsoft API calls. Finally we decided to have a session at Azure Bonn Meetup so I can do an overview session about why some Authentication flow like OAuth makes sense, anyway, and what are the advantages and issues that come with that.
This now was redeemed on June, 06th.
Thursday, June 06th – setup
This time Azure Bonn meetup took place at the Haus Müllestumpe at Bonn, Grautheindorf/Auerberg. I love that area as I has lived a small footwalk away from there for some years during my project at T-Mobile at early 2010s.
Haus Müllestumpe has a really great ambiente for a meetup like that, with a large session room and as we’ve been there on a Thursday the menu contains an all-you-can eat-schnitzel buffet. But let’s stop at that point as I don’t want to talk about Schnitzel but Azure Bonn Meetup.
My session was divided in 2 parts, following the sessions format Rene and I set up in the sessions briefing – first hour introduced attendees to reasons why we need some access token protocol like OAuth2 (and OpenID, but for a basic introduction I didn’t focus a lot on that detail level) with some basics on authentication flows.
Main objective of that intro is to get attendees aware of the role model, where users and apps are understood as different parties in authentication to Azure AD and access to resource servers. I think this is really important to understand the reasons, why you need to do so many API calls before you are able to access resource data.
Part two of this session showed example implementation code. Initially we discussed Azure AD app registration, using the legacy blade and the modern blade. yes, we did that via GUI.
And @AtholyMardies just won’t stop explaining 😉. Full house at late hours! #AzureBonn #OAuth2 pic.twitter.com/2YsvLqBKh4
— Azure Meetup Bonn (@AzureBonn) 6. Juni 2019
While we’re talking about the blades: I really can confirm that the web interface is really intended to push a user to use the command line or API. On the other hand, sometimes a GUI is useful to explain where and why to find configuration data, like your OAuth2 endpoint, application ID and application secret.
I’m really proud of me that I remembered all the clicks in the Azure AD app registration blade!
Now that we understood how to setup an app against Azure AD, we discussed Azure Environment and user realm discovery in PowerShell code. Following that we discussed the authentication flow for a user, using the grant types for a token, like password, user code and device code.
We did a closer look at the JWT token and its representation as the result of convertfrom-json as a PowerShell object. That way we had a deeper understanding about what’s really included in this token compared to what you can see in your object.
From a result explained by a Fiddler log, we also discussed why the grant type “password” maybe is one of the worst ideas to implement in your own code.
Downloads and example code
Before I provide the code and slide deck from my session, I’d like to again say “Thank you!” to all my sessions attendees.
Please remember the reasons why the example code is not ready for use in your production and why you really should protect your users with an additional auth factor, like MFA. And also please keep in mind why Windows Hello for Business on the one hand is a good alternative for your password authentication but still keep in mind how we took away the authentication information to use it instead of the original authentication. That is why I personally rather prefer MFA using the app over Windows Hello for business, although it is a bit less conveniant to type in the numbers.
Now that we have it clear, please check out my repository for download from https://github.com/MartinGudel/AzureBonnMeetup-AzureADAuthentication-with-PowerShell