Home

Podfeet Podcasts

Security Bits logo - a green padlock with the words Security Bits to the right and in tiny letters below ithat it says 10101010 indicating a digital lock

Security Bits – 2024-06-23

  • by Bart Busschots

    • Feedback & Followups

    Deep Dive — Modern Authentication

    Microsoft have just announced that they are moving their home email users over to Modern Authentication, so this seems like a good time to explain what that means.

    Firstly, the changes Microsoft are making:

    1. Users of Outlook.com, Hotmail.com & Live.com email will need to switch to mail clients that support modern auth before the 16th of September 2024 (all modern mail apps do, including Outlook on all platforms, Mail.app on Apple’s platforms, and Thunderbird).
    2. Support for Microsoft’s stand-alone Mail and Calendar apps is ending at the end of 2024, with users being migrated over to Outlook.

    Full details: www.bleepingcomputer.com/…

    Modern Authentication is both a somewhat vague industry buzzword and a piece of very specific Microsoft jargon for a collection of protocols and processes within their services. I’m going to take the broader view here.

    The best way to explain modern auth is to contrast it with what has come before. I’m going to refer to the old approach as legacy authentication, though Microsoft’s official jargon is the less judgemental basic authentication.

    The Old Way (Legacy Auth)

    One account has one password, and every time a user or any app acting on their behalf tries to log in they send both their username and their password to the website or server.

    What’s wrong with this?

    1. Every app needs a copy of your password saved in it somewhere! You have to trust all of them to do that securely, and not to phone home with a copy of the password.
    2. You can’t revoke access on an app-by-app basis, your one password is all you have, so your only option ever is to change your password and re-configure every app
    3. If apps authenticate via usernames+passwords, then there’s nowhere to hook in additional protections like 2-factor/multi-factor authentication, or entirely new alternatives like Passkeys

    The workaround for these shortcomings has been app-specific passwords, which are just very very long truly random passwords. These are less bad than human-chosen passwords, but only a little.

    The New Way (Modern Auth)

    Modern Auth separates two important concepts — Authentication & Authorisation.

    Authentication is about proving your identity, while authorisation is about granting specific permissions.

    There are a few protocols that enable modern authentication, but regardless of the protocol, the key concepts are the same.

    With modern authentication there is a single identity provider (IDP) for all sites and services associated with an account, and that identity provider is the only place where authorisation happens. Instead of the mail server and web server doing their own authentication, it’s always done by the identity provider.

    The identity provider then issues an authorisation token that contains the following:

    1. basic account details (some mix of user ID, username, email address, name, etc.)
    2. an expiration time for the token
    3. a list of the specific things the token may be used for
    4. a digital signature to validate the token

    On the web these tokens get saved by the browser as first-party cookies (not the evil kind), which is not really all that different to the old-fashioned session cookies that are used with legacy auth. Where you see a real difference is in apps — with modern auth, apps do not store usernames and passwords, they store authentication tokens!

    Because an app now only has a token, not the actual username and password, you can revoke any app’s access at any time by revoking the token on the identity provider (usually via some kind of My Account web interface).

    The other big advantage is that an authorisation token does not give blanket access to your account, it only gives the access your app needs (assuming things are properly configured of course). So, if you authorise your mail client and give it permission to read your email and send email, then even if that token is stolen from the app, it can never be used to log into your account on the web and start changing your settings, or to update your calendar, or to buy a load of stuff in the store or …

    What Does Modern Auth Look Like to the User?

    That sounds great, but how does all this work from our point of view? Let’s step through the process. As an example, let’s assume we just downloaded a copy of the wonderful Fantastical calendar app for Mac, and we want to connect it to our Google Calendar, what do we see?

    1. When we try add our account to any app the app needs to send us to the web interface for the matching identity provider. Apps can do that by bouncing us into our default browser, or, by popping up a web view in a little window within the app. These days the browser option is preferred so people can use their password managers! In our example the Google Login page would open in our browser and ask us to log in.
    2. After we authenticate our IDP it will show us the list of permissions the app is requesting, and give us a button to authorise the app. That will generate a token with just those permissions, and we’ll then get presented with a button to return to the app. Clicking that button will send the token to the app which will save it.
    3. Each time the app talks to the server it will present its token, and the server will:
      1. Check with the IDP that the token hasn’t been revoked
      2. Check if the request made by the app is covered by the permissions in the token
      3. If all the checks pass, do what ever the app asked and return the result
    4. When the token expires or is revoked the app has to send us back to the browser. If the token just expired then we simply re-authenticate to refresh the token, no need to grant permissions or anything. If the token was revoked we have to issue a whole new token so we do have to approve the permissions again.

    How Does Modern Auth Enable 2FA/MFA/Dongles/Authenticators/Passkeys etc?

    Once apps or services update to support modern auth, they are completely removed from the authentication process — authentication becomes the sole responsibility of the IDP. Now, the IDP can be updated to support any new authentication technology without any of the apps or services needing to be updated at all.

    Before modern auth, every protocol and every server had to accommodate the details of how users authenticated — websites, email protocols, calendaring protocols, everything, had to have the UI, data fields, and processes for dealing with usernames and passwords. Every app had to have a way to store them, every protocol had to have a way to send them, and every server had to be able to validate them. Adding something like a second factor meant re-engineering the whole thing with a new UI in the app, new fields in the protocols, and new processes on the servers. Each different scheme required different UIs, fields, and validation processes, so the end result was that most protocols and apps didn’t get updated — hence the need for app-specific passwords as a workaround.

    With modern auth, apps, protocols, and servers need to be updated just once to support one or more of the token-based protocols, and then they’re good for the foreseeable future! Authentication is just not their problem anymore!

    As well as enabling an ever-expanding range of authentication options by giving sole control of authentication to the IDPs, modern authentication also breaks the one-to-one mapping legacy authentication employed (one account, one password). IDPs can allow you to register as many authentication methods as you like on any given account, and most do. You can then authenticate with whichever is most convenient in any given situation. You could register a passkey from your phone, another from your spouse’s phone, a FIDO 2 hardware token that never leaves the office, and so on.

    Note that IDPs really are free to do whatever they want to authenticate you. They can use any open standard like TOTP (Google Auth-style codes), FIDO hardware dongles, Passkeys, etc.. But they can also do their own thing, hence custom authenticator apps like those from Adobe & Microsoft, and in-app authentication options like GitHub (no separate authenticator app, but their main app can auth you to their website).

    Modern Auth is Well-Bedded In

    The push to move away from legacy auth started in the enterprise, and it has been in progress for over a decade.

    At this stage, we have a small well-defined, and well-tested suite of protocols. For home users, it’s really mostly OAuth2, while enterprises use SAML2 and/or OIDC to do single-signin across first and third-party sites. If a home user uses ‘sign in with’ buttons they are probably using OAuth2 (log in with Google & login with Meta), but it might be OIDC (Stack Exchange supports OIDC). The user experience is the same regardless — click to log in, get bounced to your IDP’s website, prove you are you, and get redirected back. The key point is that these protocols are all very mature now.

    Microsoft actually disabled basic auth for their enterprise customers at the end of 2022, so all apps that can connect to education and corporate Office 365 accounts already support modern auth! Those 2 years of enforced modern auth on literally millions of people have pushed the apps to update 🙂

    in case you’re wondering, Google is a little behind Microsoft in terms of forcing the use of modern auth (not in supporting it, just in requiring it), but they too are ending support for legacy auth this ‘autumn’.

    A Note On Passkeys

    There are two ways Passkeys can be used for authentication, and both fall under the broad umbrella of modern authentication:

    1. Direct Passkey support via the WebAuthn protocol. The app/website directly supports Passkeys and there is no IDP involved.
    2. Passkeys as one of the registered factors on an IDP. The app/site doesn’t use WebAuthn, they use one of the modern authentication protocols to send users to an IDP instead, and the IDP uses WebAuthn to handle Passkeys.

    The Bottom Line

    This shouldn’t be too bumpy a ride for home users, and it will bring a lot more security.

    ❗ Action Alerts

    Notable News

    Top Tips

    Excellent Explainers

    Interesting Insights

    Palate Cleansers

    Legend

    When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart

    Emoji Meaning
    🎧 A link to audio content, probably a podcast.
    ❗ A call to action.
    flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
    📊 A link to graphical content, probably a chart, graph, or diagram.
    🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
    💵 A link to an article behind a paywall.
    📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
    🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top