How to implement SSO with multi back-end services and decoupled architecture

user_4097712 0
Viewed 958

BACKGROUND:

There are several services (spring boot REST API services and some other productions with REST API) as back-end and some angular applications (some web site with different second-level domain name) as front-end.

One front-end application can call some back-end services using asynchronous method (they are under the same domain by reversed proxy, so no CORS problems).

TARGET

SSO, viz. if a user logs into a front-end application successfully, the user should access other applications without login again. (Of course, in the same browser with cookie enabled)

QUESTIONS

  1. Should REST API follow Client Credentials Flow (return 401 if not authenticated) or Authentication Code Flow (return 302 if not authenticated) ?

Many documents/tips/posts suggest REST API should follow Client Credentials Flow because it is stateless and do not know the redirect uri. However, if I'm not wrong, it is impossible to implement OSS using Client Credentials Flow otherwise all back-end services should be the same client in keycloak which could share client_id and client_secret.

If using Authentication Code Flow, the problem is how the front-end could retrieve response data after a user successfully logs in. The process is something like:

front-end             back-end     keycloak
    |  -- asyn call -->  |
    |  <-- HTTP 302 --   |
    |  -- redirect to login page -->  |
    |     <-- redirect to where ???-- |

  1. If the answer to question 1 is following Client Credentials Flow, then is it the best practice to share the same client_id and client_secret between several back-end services? Or are there any other solutions?

  2. If the answer to question 2 is following Authentication Code Flow, then how to handle the asynchronous REST API calls after successfully log in?

spring-security-oauth2 keycloak spring-boot spring-security single-sign-on
1 Answers

1.) SSO Protocol

Open ID Connect should be used. In theory there is also SAML, but that one was designated for the web app, not for SPA apps/REST APIs.

2.) Frontends (SPA apps) manage authentication

You need user identity, so client credential flow is not correct. You need Authorization Code Flow with Proof Key for Code Exchange (PKCE). Use mature (OIDC certified) libraries (e.g. https://github.com/damienbod/angular-auth-oidc-client) and they will manage everything (token refresh, authorization of routes, logout, ...). You don't need any libraries with the Keycloak in the name (OIDC is the standard, which must be implemented, not a Keycloak). Fronted adds access token to each API request (e.g. with Angular interceptor).

3.) Backends (REST APIs) just verify token

Calls from the frontend are XMLHttpRequest requests - they are in the background. It doesn't make sense to have 302 response (redirect to auth). Users won't be able to see that, so that's the reason why 401 Unauthorized should be returned (then frontend can have own business logic how to handle that - e.g. redirect to auth). So backends don't need to implement any login flow. They only verify validity of used token in the request. Eventually, they do an authorization, e.g. only users with some particular groups/roles can perform same actions - only editors can edit, only admins can delete, otherwise respond with proper response code - 403 Forbidden.

user_33486040
Related