Authentication API and Enterprise ADFS

Help
1

Encountered an authentication issue that seems pretty unique and was wondering if we could get some pointers. We have a single page application written in Angular talking to a REST API on the backend. The normal flow is for the Angular client to log the user in, then send a Bearer token in the authorization header every time a request is made to the REST API, which does a check on its end before responding.

We also have two main types of users, those external to our company and our internal users. External users log in with the typical username/password and are stored in the Auth0 database, whereas internally we’ve set up an Enterprise ADFS connection to authenticate users and check group membership in our own Active Directory. Using the Angular client, both types of log in result in the client receiving a Bearer token that is then passed to the REST API on every request it makes

Our API test automation team is trying to develop a test suite that requires them to write cases specific to each type of user. For the external ones, it’s been easy enough use the Auth0 Authentication API’s /oauth/token endpoint and pass it grant_type = password along with username, password, and client_id to receive a bearer token.

The problem is we can’t figure out the equivalent thing to do for our internal users. Even though our ADFS setup does result in our internal users being stored in the Auth0 database after their initial login, using /oauth/token with grant_type = password does NOT work for this type of user the way it does for external ones (and also seems incorrect to attempt anyway based on the Authentication API documentation).

So the question is, how do we proceed to get a token for our internal users using the Authentication API? Our normal setup funnels folks through the ADFS authentication path if their email domain matches our company’s at the login prompt, but we’ve been having a heck of a time figuring out how to use the Authentication API to do something equivalent and also return a bearer token at the end of the process. To further complicate matters, our dev and test ADFS instance is configured to prompt for a user and password when you hit it (to let us mock authenticate as other company members in lower environments), and it’s not clear how to deal with that using your API.

Thanks in advance for your time. Any help is much appreciated!

1 Like
2

Hi @nbarbas - welcome to the Auth0 Community!

First of all, I would like to thank you for being very thorough in explaining what you are doing and what you are trying to achieve. This helps us a lot to provide you with an answer relevant to you. Now, to the technical details!

To explain what’s happening and what you are seeing, I think it’s good to explain what you are executing.

When you use the /oauth/token endpoint with grant_type=password, you are executing a Resource-Owner Password Grant, which is meant to be used in secure environments (like these!) to obtain a token. This is allowed because the contact is made directly from a secure environment (your server) to Auth0, so we both trust the delivery method. ROPG is only available when the Authorization Server (in this case, Auth0) knows the user credentials and can validate them. You can read more about the ROPG here: Resource Owner Password Flow.

For ADFS, the password is not stored directly in Auth0. Instead, we do what’s known as a federation, which allows us to call ADFS and ask them to verify the user’s identity. ADFS then authenticates the user and sends a response back to Auth0, saying, “yes, they are User A, and these are their properties,” or “no, ignore this, error, error!”. At no given point in time, Auth0 handles the ADFS’ users’ credentials - the user logs into ADFS directly, and we obtain a response.

Here is the problem when testing out this scenario. There is no non-interactive way to achieve this flow unless ADFS is set to provide you with a default response. We do allow going directly into the Identity provider by using a connection parameter in your authorize request (see more here), but the Identity Provide would require having an interactive session unless you want to mock those as well.

With all of this information, I am wondering if you would like to explore other scenarios on how you could handle this apart from the original test.

Let me know if you have any further questions - hope this helped.

3

The above is not technically accurate from a point of view of support for this flow in ADFS connections; although there are indeed considerations around usage of ROPC grant, at this time and per (Call Your API Using Resource Owner Password Flow) it may be possible to use this flow with:

Make sure your connection is capable of authenticating users by username and password (for example, database connections, or AD/LDAP, ADFS, or Azure Active Director enterprise connections).

Due to how this flow works there may be additional requirements, in particular, the ADFS instance would need to be accessible/reachable over the Internet and be configured to support this flow as well, but from a technical point of view this should be doable because although I haven’t tested this recently I believe the documentation is still accurate.