Authorization with username password form

r.od.akker

We are developing an Angular app with a REST API. For this API we use the SRP HTTP Framework. We would like to authenticate users with their credentials. We already have a table where user information is stored. After authorization we should be able to identify the user as well, on the server side.

So if I understand correctly, how this normally could work, is that we send the username/password with a POST request to our API. We validate the credentials, and then we return a bearer token. This bearer token is then added to every request, which allows the server to authenticate and authorize them for the specific request.

I tried consulting the wiki to find how we can best do this, so that we stay as close as possible to the framework. The wiki describes a HTTP Basic Auth, but I think this is a little to basic for our application.

I believe that there is already a mechanism in the framework that will extract the Authorization header and then validates the token. We would like to know how this works and how we can fit it into our application.

DonBakke

The SRP HTTP Framework is designed to support HTTP Basic Auth out of the box (as you noted), but there is no pre-built mechanism to support other types of authentication without some changes. Fortunately, the SRP HTTP Framework, especially the HTTP_Authentication_Services service module, is designed to be extensible to support your requirements.

Before I give you some tips on how to implement this, I should note that best practice is to separate the authentication server from the API server. Many of our clients work with 3rd party identity providers. We've done a fair amount of research on self-hosting solutions as well. You can do this within OI, but it is less secure. I'll proceed as if you intend to do this all within OI.

You'll want to create a dedicated API to handle the bearer token. We've already created an OAuth_API for this, but you'll need to add the methods and handler code to do what you want it to do. If you want to create a simple bearer token (i.e., not a JWT, which is much more complex), then you can use the RTI_GreateGUID function to do this reasonably well.

In the HTTP_Authentication_Services module, there is code in the AuthenticateRequest service that will retrieve the content of the Authorization header as you noted. As written, it assumes that the header will only contain a username and a password. I suggest you update the code by checking the URL (there is a local variable, FullEndPointURL, which has already been populated) to see if the endpoint is "/oauth". If so, then use the current logic that assumes the Authorization header contains a username and password. If not, then branch to logic that assumes the Authorization header contains a bearer token.

The above is a bit of simplification of what you could do, but I think it will put you on the right path. There are a couple other things you can consider doing:

1. Instead of always passing in the Authorization header, implement a cookie. The cookie can be used to expire the bearer token without having to rely on an internal database.
   
2. JWT has become a very popular OAuth solution. We wrote a utility that makes it easy to verify JWTs. This is a separate commercial product, so contact me by email if you are interested in learning more.
   

r.od.akker

Okay, thanks for your pointers. Since you seem to have done extensive research already, can you maybe tell us what third party would be one of the better solutions. Maybe one for self hosted and one for cloud hosted?

The problem, I think, is that we have all the user data in the OI application. So if a new user is created in OI, how would we match this with the third party authentication service?

Still we have a better idea where to implement things if we create a custom solution.

DonBakke

I'll have our in-house OAuth SME respond with some 3rd party suggestions.

As I recall, keeping these providers in sync with your local user data can easily be handled through an API call. You can hook into your user form (i.e., Write event) or table (MFS) and immediately send or queue up the API request to the 3rd party provider.

[Deleted User]

There are an incredible amount of 3rd party solutions available today. Which 3rd party solution will suit your needs best ultimately depends on your requirements.

For a self hosted solution I recommend Midpoint and for a cloud hosted solution I recommend Auth0.

Gartner's Magic Quadrant for Access Management white paper provides an in depth comparison of the top commercial solutions available today.