Tyk + Okta: Session state is missing or unset! Please make sure that auth headers are properly applied

Hi,

I’m using Tyk as SaaS, that is, not hosted by me. I’m trying to make an API accept JWT access tokens generated by Okta. It’s based on the “service credentials” flow:

  • The client application uses its client_id and client_secret to request an access token from Okta.
  • Then, it uses that token as bearer in the Authorization header, when it tries to access a protected api in Tyk.

The json of the API is tyk api definition - Pastebin.com

The error I get is “Session state is missing or unset! Please make sure that auth headers are properly applied”, in the “MIDDLEWARE: Key expiration check” step.

The API has attached a default policy with no keys, and the “Public key” section of the JWT points to https://dev-2237251.okta.com/oauth2/default/v1/keys/

I assume Tyk accesses that url looking for keys matching the “kid” of the JWT. However, I don’t understand why the expiration check fails, nor which key is being checked in the first place.

I also tried to create a new token in Okta and create a key in Tyk using that token in the JSON Web Token ID field, and associate that key to the policy attached to the API, but it didn’t work either.

Detailed logging doesn’t work for me neither for the API nor any of the keys I used when trying to make this work.

Any ideas or links where I could figure things out on how to, using client credentials, make Okta generate access tokens that Tyk can use to grant access to its APIs?

Hello @chous,

Welcome to the community :tada:

Sorry, you’re experiencing this issue.

Your API definition looks about right, I think it may have to do with the client setup on Okta :thinking:.

Can you review the Okta setup here? Step by step guide using Okta.

The DCR setup flow is equivalent to manually creating an APP integration with a “Sign-in Method” of OIDC and Application Type, Web Application.

If you still run into issues, you may share your gateway URL so I can check its logs for more information. Call the API and the time range you do so.

Hi,

Thank you very much.

I’m following the guide, but I get this error when trying to create an Oauth client:

“You can only connect one API to an OAuth client.”

https://advanced-conga-dev.aws-euw2.cloud-ara.tyk.io/oauth-clients/new

Mmm… You’re trying to create the client through Tyk? Or on Okta?

I can see you’re using Tyk 3.0.9. The Dynamic Client Registration flow through Tyk was introduced later, so I don’t think you can create a client that way.

Regardless, if properly set up, the gateway will grant access to Okta-generated tokens.

In Okta, you should create an App integration with a “Sign-in Method” of OIDC and an “Application Type” of Web Application. Setup default scope as well, as shown in the referenced guide.

I was following the guide, to figure out if I missed something when I created the application correctly in Okta. As I see, the application in Okta seems fine.

To provide more context, we have two applications in Okta. One (application A) is using openid connect to perform sso and be able to log in into the Tyk portal. The other one (application B) is supposed to create access tokens accepted by Tyk to access protected APIs.

Could you give me hints of what I am assuming incorrectly?

  • The client uses client_id and client_secret from application B to perform a post to Okta’s SSO url.
  • Okta returns a JWT in which the kid is generated from keys Okta manages (and rotates) itself.
  • The client performs requests to an API protected by Tyk, using Authorization: Bearer [jwt] as header.
  • Tyk accesses the url associated to the API (in the jwt_source field), analyzes the json, and takes the one that matches the kid of the JWT.
  • Tyk verifies the JWT is signed with the key retrieved from the url that matches the kid.
  • Tyk performs some other checks if necessary.
  • Tyk allows the requests and forwards it internally to the target endpoint.

Is that correct?

Back to the error message, any hints?

Hi,

If you can see the logs, I’ve done some tests on the API, from

Thursday, 17 November 2022, 15:00:00 UTC

to

Thursday, 17 November 2022, 15:30:00 UTC

Thank you very much!

In your API definition, please clear the “base_identity_provided_by”.
"base_identity_provided_by": "",

It would appear the issue is the JWT authentication module is not permitted to save the key it created because the API Definition has the “base_identity_provided_by” specified as “oauth_token”, which means the standard OAuthentication token was recognised as the auth method that should provide and save any key. After the authentication step key validation checks failed because no key was in redis/cache to retrieve and check.

2 Likes

You’re right, it fixed the problem.

Thank you very much!