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.
Pop-up vs redirect flow
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 key difference here is that the pop-up flow leaves the app intact, does the auth in a separate window, then returns the token to the app from JavaScript. The redirect flow leaves the app, does the login, then redirects back to the app.
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.
Storing Access Tokens
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.
Passwordless login
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).
Auth0 supports passwordless login too
More technical details
- 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
Is there a use case for server-side secrets?
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.
Top comments (0)