CODEWITHSUNDEEP
windowsoauth-2.0single-sign-onkerberos
Geob-o-matic
Geob-o-matic

Reputation: 6079

In OAuth2 flow, can we delegate authentication to Windows SSO

We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).

Is there a way to do that?

Upvotes: 0

Views: 965

Answers (1)

Gary Archer
Gary Archer

Reputation: 29291

That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.

Most commonly:

  • The AS might be hosted in the cloud
  • It will redirect browsers to an on premise Identity Provider (IDP)
  • The IDP can connect to Active Directory

You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.

If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.

Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.

REQUEST FLOW

Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:

  • Your apps will make a standard OpenID Connect authorization redirect to the AS
  • The AS may then present an authentication selection screen to the user, unless there is only a single option
  • Alternatively an app can send the acr_values query parameter to say which authentication method to use
  • The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
  • The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
  • The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
  • The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
  • Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket

Upvotes: 1

Related Questions