1

We have a Java 8 backend application using SprintBoot with an embedded Jetty server.

The UI for the application is a Single Page Application built using React.

Currently I have enabled authentication by integrating with Okta using the spring security SAML extension. When the assertion is posted by Okta to my app, I create a session and the JSESSIONID is sent in the cookie.

This was fine until now when we had a very simple UI serving few UI components.

However, now we have several REST endpoints in our backend and we would want them to be authenticated as well. REST endpoints themselves are developed using Jersey.

If I understand correctly, SAML is clearly not the choice for pure REST based endpoints as SAML is mainly a browser based protocol. These REST endpoints will be called by our UI as well we want them to be independently called via Postman or something for testing.

When a client would call these REST APIs, I am guessing the client should send an Authorization header which should be checked by one of the authentication filters in the backend. After validating the client and the user, the filter should inject the user information in the SecurityContext because Jersey injects SecurityContext in all of the REST endpoints. Then it becomes easier to fetch the user from this SecurityContext.

Upon reading, it seems Okta OpenID Connect can be one choice which issues a JWT. However I am not clear on how to use this. That is, when Okta issues a JWT should our UI or any client for that matter keep sending the JWT in the Authorization header to our APIs and then our APIs in turn should send the JWT to Okta to validate it?

Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints? Not to mention the REST APIs will be stateless in nature.

user320599
  • 191
  • 1
  • 11

1 Answers1

1

When a client would call these REST APIs, I am guessing the client should send an Authorization header which should be checked by one of the authentication filters in the backend

In OpendID Connect (OIDC), that value in the Authorization header is id_token which can be in JWT format. This id_token is issued by the OIDC server as the last step for whichever OIDC grant type you choose and applicable to your case.

Upon reading, it seems Okta OpenID Connect can be one choice which issues a JWT. However I am not clear on how to use this. That is, when Okta issues a JWT should our UI or any client for that matter keep sending the JWT in the Authorization header to our APIs and then our APIs in turn should send the JWT to Okta to validate it?

Think that you have 3 components in this architecture. Relying Party (client), Identity Server / Authorization Server / OIDC Provider and Resource Server (your backend and it's data). When Authorization Server issues and id_token to Relying Party, your Resource Server also knows this token. So when you request for data in resource server, you will present your id_token to Resource Server and it knows if it is valid id_token or not

Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints?

OIDC Provider (or Identity Server if you need more complex operation), since OIDC is Authorization (OAuth 2.0 at core) and Authentication.

letthefireflieslive
  • 11,493
  • 11
  • 37
  • 61
  • When my client(relying party) will present the JWT to the backend (resource server) of my application (which initially would receive the JWT from OIDC server), how the backend is supposed to validate it? It is not the one who issued the JWT in the first place. The only validation it can do is to check if it is signed with the right keys because the backend can get the signing keys from the OIDC server. – user320599 Jan 18 '17 at 17:19
  • id_token contains who the user is and what resources is he/she allowed to access. Resource server only checks if that id_token is valid to access such data. For simplicity you can think that authorization/identity server share the same database of id_token to resource server. – letthefireflieslive Jan 19 '17 at 02:31
  • Actually a slightly different question. I already have SAML integration done with Okta. However, the API calls the UI makes to the same REST end points need to be authenticated as well. Once SAML assertion is received by my app, the HTTP session is created. Now how to leverage this for the API calls the UI is making because the HTTP session is there in the browser. If a REST end point is authenticated what should be UI send when it is making the same API calls? Note - I have not integrated with OIDC yet. – user320599 Jan 20 '17 at 19:59
  • Is above mentioned problem solved with given solution? If so little more details help to understand it better!!! – Seshagiri Aug 12 '17 at 16:31