Auth Series 5: The Other Stuff

11 Dec 2024 by cthos
1560 words

Welcome to the last post in my end-of-2024 Auth series. This post covers the "other" stuff that I didn't cover in the previous 4 posts. It's mostly just the fun wrap up post to hit some things you probably won't need to know about but might want to know more about.

So, here's the list:

• OIDC/OAuth other flows (M2M and Device Pin)
• Certificate/Ticket based SSO, like Kerberos
• Mobile device management and certificates

Let's get right in!

_{CeltStudio @ Shutterstock #2179196459}

If you have a "smart" device without an easy way to type in your password, like an internet-connected TV, or refrigerator, or light bulb (or something) you might have seen the OIDC device flow.

Basically, when you request to log into a service, you give it your username or email, and then it will show you a short (usually) code. You're expected to go grab your phone or computer, log into the service over there, and enter the code to bind your device to your account.

Auth0 has a nice flow diagram of this flow. The things you want to note about this are:

1. The URL you use to generate the code is different from the usual URL you'd redirect users to in interactive mode.
2. Your device has to poll for access to /oauth/token, there's nothing in the standard that gives a push (but I suppose you could implement your own push solution).
3. How you bind a device to the account is up to you, and will depend on the device in question. Your application could generate it itself and store that locally, or you could use a unique device ID from the platform as appropriate.

Did you know there's an OAuth 2.0 grant where you collect the user's username and password directly and send it to the resource server yourself? Well there is! You probably shouldn't be using this grant for anything, but sometimes there's no other choice. It's pretty much only okay in a first party scenario where you control both ends, but I've seen it used as a shortcut in a lot of places rather than showing an OIDC style redirect.

The flow is really short:

1. Prompt the user for their username and password.
2. Send that directly to the oauth/token endpoint and get an access token back.

Now, it's worth noting that this flow has been removed in OAuth 2.1 because it's not nearly as secure as the other options.

The last one I want to touch on a bit more than I did in the SSO post is the client_credentials grant, which is designed for use in Machine-to-Machine scenarios. It exists outside the context of a user, so this grant type tends to either be very privileged or limited to a small number of scopes.

This requires the pre-sharing of secrets between the authorization server and the client and as such it requires a client_secret. Ideally you get this secret to the client securely because anyone in possession of it will be able to log in with this grant.

The flow is dead simple:

1. Send the client_id and client_secret to the /oauth/token endpoint and get an access token back.

How long that token is good for is typically configurable at the authorization server. Auth0, for example, defaults this to 8 hours (and they charge based on how many times you do this).

You'd use this grant if you have some backend that needs to interact with protected resources, and the client can be restricted to requesting certain scopes.

_{David Dirga @ Shutterstock #358007024}

Like other things I've talked about, Kerberos uses cryptography to use its magic, and it can work with either symmetric or asymmetric keys.

For the symmetric flow, it works kinda like this:

1. The user sits down to a computer and types in their username (or provides their identifier some other way).
2. The Authentication server does a lookup to see if that client's registered, and if it is, it'll encrypt a session token with the user's password (or private key) and send that back to the client.
3. The client enters their password which is used to try to decrypt that key.
4. Assuming everything goes well that session token is used for any further communications with the server.

There a few different ways to do this, all of which I'm only familiar with on the end-user side of things, but you'll find this a lot in corporate environments, and you usually won't have to think about it or even realize it's happening. One example is being able to log into corporate Wi-Fi and have any internal applications already know who you are. I've seen this implemented using a CBA solution, where a certificate is pushed to the device in question and that certificate is then used to authenticate the device to the network.

CBAs require you to set up a Certificate Authority (CA) that can issue certificates and is trusted by the device (which you can force via the next section).

Basically, the way that this works is each certificate can contain information about the client encoded in it, which is signed with a private key that only the CA holds, so you can use that certificate to validate who the client is and that their client certificate has not been tampered with.

How this works in practice is that when you're authenticating with something, you can send that certificate and have your backend verify the Certificate with the CA and then make authentication decisions based on that. But, to get this to work with websites magically... you have to do some interception shenanigans. For example, having the device use that certificate instead of ... regular SSL certificates.

And how might one do that? Let's talk about Mobile Device Management.

If you're working at a big company and your work computer was issued by an IT department, you probably have some sort of MDM installed on your device. MDMs allow a centralized server to do all sorts of things to that device, like install applications, remotely wipe the machine (in the case of loss or theft), or identify the machine to the network. We're going to focus on that last part.

One major MDM vendor is jamf, and it's the one I've got the most experience as an victim end-user of. On Mac, it uses the same certificate process to gain control of the device (and shows you exactly what it can do in that certificate).

So, remember the section right before this where you can install a trusted CA on a device? Using an MDM is a way you can do this (you can also image the machine before sending it to the end user, but then you have to worry about updates somehow). So, here's how an MDM facilitates the magical auth from the section above.

1. Have the MDM solution identify a user via whatever auth mechanism you want (installing an MDM profile and then having them log in for credentials is what I've seen).
2. The MDM and the CA create a certificate for the user and device and pushes that certificate to the device.
3. The MDM configures the client machine to both trust and use that CA for all of its traffic.
4. Additional shenanigans are in place to configure say a browser to use that certificate essentially as a man-in-the-middle to intercept traffic and present that certificate to a website or internal application to do auto-logins.

That does mean that the traffic going to those (or all) websites is encrypted by the custom certificate meaning the company can see encrypted traffic to those websites. For an example of someone figuring this out, check out this Stack Exchange post. Because your certificate is also unique to you, they can introspect that traffic.

But yeah, it is pretty magical not having to type in your credentials to business applications.

Right, we're done here. I hope you enjoyed this series. If you'd like to see more long-form deeper dives on topics, let me know on the socials or here in the comments.

authentication blog kerberos oauth