Okta Authorization Integration - 401 Unauthorized

Nikolay Megdano
Tera Expert

I am trying to set up Okta authorization on my environment following this guide.

I am able to successfully receive token in Postman, but when I try to access any resource from the servicenow instance(ex: /api/now/table/incident?sysparm_limit=1) using the generated token I get "401 Unauthorized" error:

{"error":{"detail":"Required to provide Auth information","message":"User Not Authenticated"},"status":"failure"}

In ServiceNow logs I can see the following error:

Cannot find oauth_oidc_entity for issuer https://dev-XXXXXX.okta.com with any of the following client_ids: https://dev-XXXXXX.okta.com: no thrown error

I've double-checked the Application registries and Providers and everything is correctly set according to the tutorial.

Any help is appreciated! 🙂

1 ACCEPTED SOLUTION

Nikolay Megdano
Tera Expert

I managed to get it working. Here are some key things to have in mind when doing this integration:

1. When a token is received for verification then ServiceNow checks against the Application Registries for the proper one. It matches the Audience("aud") claim received with the JWT token to find Application Registry with the same client_id. So "aud" in the JWT token should match "client_id" in your Application Registry.

2. In the tutorial mentioned above we set the OIDC Provider Configuration to authorize when a match is found between ServiceNow users' emails and the "email" claim from the JWT token. However when you create a simple Okta authorization server you don't have this claim included by default in the JWT token. You have the email in the "sub" claim so either set the OIDC Provider Configuration in ServiceNow accordingly to use "sub" claim or just edit your Okta Authorization Server(Okta dev portal) claims to include an "email" claim with the proper value.

View solution in original post

9 REPLIES 9

Hi there,

By the error it seems that you haven't set the "aud" to match your client_id.

Go to your okta admin panel then Customization->Authorization Servers and then double-check if you have set the Audience to match your client_id in ServiceNow Application Registry. 

find_real_file.png

 

minaz
Giga Expert

Thank you so much for responding.

I tried your suggestion and that did not help:

OKTA Authorization Server:

find_real_file.png

 

ServiceNow Application Registry:

 

find_real_file.png

 

OIDC Provider Configuration:

I tried both User Claim: email and sub

with both True and False on JTI Claim

 

find_real_file.png

 

Hi there,

 

Did the errors on both sides ServiceNow/Postman change or they stay the same?

Also I noticed that in the OIDC Metadata URL in ServiceNow you are pointing to your "default" okta authorization server(by not specifying the id it goes to the default) but from the screenshots it seems that you use another Authorization server created in okta with id aus5puezgkCiJAKwx5d6 so your OIDC Metadata URL should be 

https://dev-85627093.okta.com/oauth2/aus5puezgkCiJAKwx5d6/.well-known/openid-configuration

 

 

 

If you still have the problem after these corrections you can paste here the errors(if they are different) and also one JWT token so I can inspect it to check if it has the necessary parts.

minaz
Giga Expert

Nikolay, thank you so much for helping me on this. Although I haven't been able to make it work, I have learned a lot.

I was wondering if you can provide me your personal email address at shaz_b@yahoo.com

I will provide you access to my PDI and the OKTA Instance. That way, you can actually take a look and help me figure out where am I going wrong.

I was thinking of taking screen shots but I thought direct access would be much easier.

If you are up to it off course.

Thanks.

J_r_me Lambercy
Tera Contributor

Postman ID Token from Okta.png

Tx Nikolai, indeed Now Platform has to match the aud value against the client_id for this to work.

 

In Postman, when you manage to get your access token from Okta, simply switch "Use Token Type" to "ID Token". The correct token will then be used and the request will work (both "aud" and "email" are contained in the ID Token).