Thanks to everyone who came to Scottish Developers to see myself and Christos talking about identity. If you missed it, be sure to watch again on YouTube. Many thanks to Carole and Andrew for getting Scottish Developers back and running again.
If you want to review the slides, they’re available here – if you want to use them yourself, please let me know.
Don’t share secrets in your SPA. Use PKCE instead.
During the session, a few questions came up that I want to put here for the permanent record.
If you were watching myself and Christos closely, you may have noticed that I was using the redirect flow in my examples, whereas Christos, and most of the Microsoft examples, use the pop-up flow.
The popup flow is thus easier to develop and work with, but it doesn’t work on browsers with strict pop-up settings. I’ve had to change Firefox to get it working, and I’ve never seen it work reliably with an iOS or Android browser. If you need to support IE, MSAL will fallback to redirect flow anyway.
To get the redirect flow to work reliably, you need to be able to restore state when your app gets reloaded. The best way to do this will depend on your app, but common methods would be to persist state (or just current route) in localStorage if there’s nothing sensitive, or pass the current route/state as a data parameter to the login call, and this will be returned to your callback URL, for you to handle appropriately.
Access Tokens are your secrets. Treat them as securely as passwords. Don’t use local storage for access tokens.
DON’T USE LOCAL STORAGE. DON’T USE LOCAL STORAGE.
Best option is to keep them in memory, and rely on the browser process sandboxing to keep the secret safe.
As Christos mentioned, if you use the MSAL library, it has its own credential cache that will handle this for you.
If you can, definitely prefer passwordless login. Chances are your website, or your intranet, isn’t important enough to your users for them to create a unique, secure password. Azure AD supports passwordless as well as 2FA and Hardware auth (including biometric on supported devices).
- View the PKCE spec here
- Auth0 writeup on the PKCE flow
- Auth0 writeup on building a client, if you can’t use an existing library
Yes. For backend services that don’t have an interactive login (such as timer-based jobs), and can keep the secret secure. However, where a service supports it, please use the Managed Principle approach as shown by Christos. If the service never knows the password, it cannot lose it. Let the identity provider grant trusted access on demand.
Where there is an interactive component, the OAuth flow allows the user to verify and control access to whichever subset of their data they choose.