1

We have an application that has frontend UI(Which is a web application) which communicates with a resource server. Our frontend will be using some APIs from a resource server to get data.

I am planning to add frontend to Okta and provide access to okta registered users.

In the resource server, we have some APIs that we want to expose to our customers to integrate in their system(Programmatically). To use our APIs, we have to provide client credentials(client ID/secret) to them. Using clientId/Secret, they will get access_token and will use that in a subsequent request. We can display this clientId/Secret via frontend UI once the user logs in to it via Okta.

How should I authenticate requests to the resource server from the frontend? And how do I authenticate requests to resource server via customer using clientId/Secret? Should I use one or two different tokens for this purpose?

Does Okta provides per-user client Id/secret that user(customer) can use to get access_token and send it to access resource server and resource server validate token against Okta.

Pulkit
  • 45
  • 4

2 Answers2

0

I just did something very similar. You can read about my experience here: How to pass/verify Open ID token between .net core web app and web api?

I don't know what application framework you are using (.net, node, etc), but if you're using .NET the steps are to (a) install the middleware in your web app, (b) install the middleware in your api app, and (c) make sure calls from your web app to the api app pass the id_token.

If you, in addition to that, need to secure it for external users - it should work the same way. The only difference is they will manually call the /authorize endpoint to get their token - but the middleware should take care of the token verification for you in both cases.

Note I did experience one odd thing which is that I needed to pass the id_token and not the access_token. It is also worth mentioning that the claims were interpreted differently in the app and the api (in that the name of the claims for say, userid, were different between them - the data was still the same).

Buckles
  • 161
  • 1
  • 9
  • Thanks Buckles! I went through your answer and mostly clear about how to do authentication request coming from Web App. But instead of using middleware, we are planning to use API gateway for token validation against the Okta. I am not clear how I expose this api to 3rd party developer? I have to give them clientId/secret(Not sure who and how this will be generated) once they login to UI via okta. They will use this clientId/secret to get token(who will give them token after validating client credentials). And I want to keep different clientId/Secret for each customer. How to achieve this? – Pulkit Jan 22 '20 at 06:03
  • I tried to search about it, but didn't find much details that Okta provides such facilities. So I thought of managing clientId/Secret myself and do clientId/secret validation and token generation for client to client authentication in our auth server. But with this approach, middleware/api gateway needs to be aware of two type of access_tokens, one generated by okta which received through web app and second one generated by our auth server which will come when 3rd party tries to access our api directly? What's your thought on this approach? Or any better way to do this? – Pulkit Jan 22 '20 at 06:03
0

You will have to use 2 different access tokens. There are 2 different flows going on here:

  • Web UI to API
  • Business partner system to API

Technically this means:

  • Authorization Code Flow (PKCE)
  • Client Credentials Flow

And in terms of tokens it means:

  • In the first case there is an end user represented in access tokens (the 'sub' claim)
  • In the second case there is only a Client Id claim in access tokens

I can advise on token validation techniques if needed - let me know.

To me though this feels like an architectural question - in particular around applying authorization after identifying the caller and versioning / upgrades.

Based on my experience I tend to prefer the following architecture these days, based on 2 levels of APIs: eg with these ones exposed to the internet:

  • User Experience API serves the UI
  • Partner API deals with B2B

And both entry point APIs call the same core services which are internal. Might be worth discussing with your stakeholders ..

Gary Archer
  • 22,534
  • 2
  • 12
  • 24