1

Our client wants us to implement a trusted subsystem design, meaning they have their Azure AD (Client AD) to authorize the users for the frontend. And asked us to use our own Azure AD (Dev AD) to authorize the frontend to the backend. We managed authorization flow from Cliend AD (using angular-msal library) and there are no problems. We get an access token and authorized into frontend. But then I need to request another access token from (Dev AD) without user interaction (client credential flow) using client_secret, application_id. for being able to call a secure API (our back end). That is how my backend guys propose. So after that, they can validate the second access_token on the back end and provide secure data back to the client. My question is: Is this a right and secure way to acquire an access token from the angular app using client_secret, application_id? At least when I'm trying I have CORS problem. A client also added the following description that I don't understand. If it can help to understand the problem:

When the MSAL library is used, the Identity Provider (Azure AD) can be given as a parameter when a token is requested

Vitalii Polulikh
  • 69
  • 1
  • 4
  • 1
    Never ever add secrets to client side. – Vova Bilyachat Aug 22 '21 at 23:57
  • 1
    `"But then I need to request another access token from (Dev AD) without user interaction (client credential flow) using client_secret, application_id. for being able to call a secure API (our back end)"` This is seems alright, in this case you could keep your `azure ad credential` at your `backend configuration files` or `azure key vault` these are the common practice. But why you need to keep `apps secret` on your frontend? To achieve what your backend team suggested doen't require to keep your apps credential on angular side or frontend. This shouldn't be. Let me know your update. – Md Farid Uddin Kiron Aug 23 '21 at 02:40
  • Thanks you guys! – Vitalii Polulikh Aug 23 '21 at 15:08
  • Md Farid Uddin Kiron, I'll let you know our updates. – Vitalii Polulikh Aug 23 '21 at 15:11

2 Answers2

0

Using the user's access token might not work in the case front-end is a multi-tenant app and the back-end a single-tenant app. In this case the client credentials flow between front-end and back-end would be preferred.

Saving the client secret to front-end is not secure. I would do something along the following lines:

  • store client secret in keyvault
  • define a keyVault access policy for front-end
  • at app start, fetch client secret from keyvault to front-end to a runtime variable
  • use client secret to fetch AD token
  • use AD token to call API

KeyVault access needs to be further restricted so that the front-end application only has access to the client secret (and possibly clientID and other similar data if considered "sensitive") in the keyvault.

rierjarv
  • 1
  • 1
-1

i would recommend to build your own backend-API which would be responsible for generating token using client credentials and calling secured backend api using token. Also i would recommend to use key vault to securely store client secret. You can pass user access token (token you received post user authentication) to your own backend API to secure communication between browser and your own backend api.

aakash wasnik
  • 32
  • 2