CODEWITHSUNDEEP
angularspring-bootldapsingle-sign-onwebsecurity
Raja
Raja

Reputation: 3627

SSO authentication angular application with service gateway call

We have an application which is built using Angular. And the application trigger backend REST api to display data.

The issue was,

The application use LDAP SSO authentication to validate user (It is an internal application within company so no outside users)

The steps are,

  1. If user launch the site, It will redirect to WebSec login where user provides username and password for authentication (Implicit flow).

  2. Once the successful authentication, we will JWT access token from WebSec which will be stored in session storage and that will be used as "Bearer" token for backend services.

  3. The backend service has its WebSec certificate to validate this JWT token at their side if not it will respond with Authentication error.

For Front end - We are using Angular For back end - We are Java, Sprint boot.

Questions are,

  1. Is this right way for User authentication?
  2. If so, how safe is the Implicit flow. Ref: https://www.instagram.com/developer/authentication/ - Everyone is recommending Explicit flow (Server side call). Our UI app is maintained in different server and Backend services are maintained different server.

I would appreciate if anyone provide solution on this.

Upvotes: 4

Views: 12536

Answers (2)

JohnnyDevNull
JohnnyDevNull

Reputation: 982

The best way i've saw until now is the following (I have also running a MS Single-Sign-On Server as you described), but i would recommend it doing it like Discord do it:

  1. Your Frontend Redirects to the SSO with a redirect_link and a application_id and claims to request
  2. Your SSO redirects to the redirect_link if Authentication is successful and the application_id is known, but with a random created code=$myCode, could be a JWT or whatever long string
  3. Your Frontend sends this Code to your backend, then your backend ask the SSO server if this is a valid code and requests a real authentication bearer token.
  4. If all fine your Frontend gets the real authentication token from your API

If this chain is all successful you can be pretty sure that everything is fine in your internal network. This is for company internal a good enough approach.

For external usage you can provide a secure key with step 1 and 2 that the sso have to provide back for the frontend which is generated from the frontend to be sure that this redirect comes from your SSO.

EDIT: some more details on encryption:

Your SSO encrypts the code maybe with HS512 which will be send to the client and later to the SSO again through the API. On this cycle if the SSO can decrypt and validate it and the API is a known/allowed communication partner you can say that all sides are trusted.

Upvotes: 4

msmani
msmani

Reputation: 720

The problem with implicit flow is that the JWT token is present in the URL. The implicit flow can be implemented in your Front-end or Back-end, both are not recommended but doing it in Front-end has more vulnerabilities, which is what you are trying to do, if I understood your question correctly.

I would implement it the following way.

  1. Your Front-end will redirect to WebSec login
  2. On successful login, WebSec will redirect to your Back-end
  3. Back-end retrieves the JWT token
  4. Back-end creates a one-time token and redirects to your Front-end with that one-time token
  5. Front-end retrieves the one-time token and POST the token to the Back-end to retrieve the JWT token

Upvotes: 3

Related Questions