Recently I discovered a problem with a client’s tenant. All the sudden, the authentication that I’ve used for a decade to get my command line utilities to authenticate to work wasn’t working. But it was just this tenant. No other clients had the problem, so it was a mystery as to why things were happening. Getting to the answer caused me to fire up some old neurons and get some clarity on the way things worked.
Joining the WS-Federation
Many moons ago, when claims-based authentication was still new in SharePoint, I was speaking about claims-based authentication and how it worked. I was the contract CTO for a startup who was trying to solve the authentication problem in K12. I was also helping write some of the guidance for authenticating in SharePoint with this new approach. See Remote Authentication in SharePoint Online Using Claims-Based Authentication. So, this isn’t something that’s new to me, but it is something I haven’t focused on for a while.
As I was warming up the old neurons, I began to remember that the way we bounce from location to location and server to server is a standard called WS-Federation. It’s a “passive” authentication flow where the browser bounces from place to place to authenticate a user. Ultimately, the browser gets the user to a site that authenticates them, and the site issues a ticket. This is passed back through a chain of sites until you get back to the site that originally requested authentication of the user, all the while reissuing tickets. The article above explains the process in substantially more detail.
Ultimately, it’s all about one site (the relying party) trusting another site (the issuing party) to authenticate the user That’s all fine, but what do you do when you want to authenticate in a program instead of a web browser? Well that requires WS-Trust.
A little bit of WS-Trust
A different approach, an “active” flow, is needed to take care of programs that want to authenticate on behalf of a user but can’t follow a series of redirects. Think about the program that’s calling an API: it expects the results, not a series of redirects, so WS-Federation won’t work. The good news is that WS-Trust performs the same function as WS-Federation except that the server for the API makes the request for authentication on behalf of the user. The bouncing around is handled as the servers negotiate between each other where to go and whether the authentication succeeds.
The WS-Trust standard accommodates the normal case of a username and password to authenticate a user – but it has some serious limitations in a world where we’re beginning to use multifactor authentication.
Modern authentication, according to Microsoft and others, doesn’t rely on usernames and passwords. The idea is that we’re moving to a more secure platform where users need to authenticate with something more than a username and password. This is fine, except what do you do about authenticating programs that need to take action on their own behalf or on behalf of the user? The answer is effectively a username and password.
Some will argue that the shared secrets we give to applications aren’t passwords – after all, they’re called shared secrets, or keys, or something else. However, they amount to a password, but a substantially longer password than any user could ever manage. We’ve addressed the security problem by making the password sufficiently long.
In any case, we’re moving towards greater security, which includes multifactor authentication – and that can’t be accomplished in a username/password combination way. The result is that we call the simple username/password situation “legacy.”
When Legacy isn’t Legacy
Microsoft introduced a switch that you can turn off to disable “legacy” authentication. It makes sense at some level. There’s a new modern authentication that we want people to use, and, until recently, you needed to actively enable modern authentication. So, what do you call the old approach? Well, you call it legacy.
The problem is that legacy conveys that it’s old and should be replaced or disabled. And that’s what this client did. However, most utilities that allow for a user identity associated with the results created by the tool. When they disabled legacy authentication, they broke an entire class of applications.
Modern Application Authentication
In defense, there are new ways to authenticate applications into Office 365. However, what the labeling doesn’t make clear is that those modern authentication approaches only work for a subset of the APIs. Thus, there are some places where you don’t have a choice but to use the “legacy” authentication approach.
Certainly, should we be moving to modern authentication for our applications? Yes. However, it needs to happen when the APIs we need to access work with the new authentication. In this case, the new APIs would work – if we recode the tool we are using.
So at least in this case, “legacy” may mean today –even if we’re new to the platform.
No comment yet, add your voice below!