Using useOidcAccessToken and/or useOidcFetch not Working

[radu-cs]

Issue and Steps to Reproduce

I am trying to fetch data from an API (different server that is specified in the OidcTrustedDomains.js) where the call has to be authorize using the the authorization Header with Bearer and access Token. I tried also to display the access token and the access token payload using the useOidcAccessToken hook but without success.

The hooks useOidcIdToken and useOidcUser work as expected.

Versions

• react-oidc: 6.4.0
• nodejs - 18.7.0
• Firefox Developer Edition - 105.0b2
• Microsoft Edge - 104.0.1293.63
• Windows 10 Pro 21H2 - 19044.1889

Screenshots

GET /api/v1/_**edited**_/GetD HTTP/1.1
Host: _**edited**_
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Accept: application/json
Accept-Language: en-US,en;q=0.8,de;q=0.5,de-DE;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: http://localhost:5500/
Origin: http://localhost:5500
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
authorization: Bearer ACCESS_TOKEN_SECURED_BY_OIDC_SERVICE_WORKER_default
Connection: keep-alive

Expected

• The API Calls to be authorized
• To have access to the accessTokenPayload

Actual

• The API calls receive Error 401
• accessTokenPayload returns null

[guillaume-chervet]

Hi @radu-cs ,

Thank you again for your issue. This is a normal behavior.

You need to configure OidcTrustedDomains.js and add your api url. The service worker will automaticaly add the last access_token.

// OidcTrustedDomains.js

// Add bellow trusted domains, access tokens will automatically injected to be send to
// trusted domain can also be a path like https://www.myapi.com/users, 
// then all subroute like https://www.myapi.com/useers/1 will be authorized to send access_token to.

// Domains used by OIDC server must be also declared here
const trustedDomains = {
  default:["https://demo.duendesoftware.com", "https://www.myapi.com/users"]
};

[radu-cs]

Salut @guillaume-chervet , It is configured in the OidcTrustedDomains.js. 🙂

[guillaume-chervet]

I may need more information. May you display if not a not too much secure information a sample of your first token request ?

[guillaume-chervet]

If you work at AXA you may call me :p Service worker should inject the tokens.

[radu-cs]

Hey Guillaume,

Sorry for the late reply but I was not in the office and I could not provide the necessary information. And no, I don't work for AXA. Thank once again for the quick replies!

Am Do., 25. Aug. 2022 um 17:34 Uhr schrieb Guillaume Chervet < @.***>:

If you work at AXA you may call me :p Service worker should inject the tokens.

— Reply to this email directly, view it on GitHub https://github.com/AxaGuilDEv/react-oidc/issues/843#issuecomment-1227431103, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIBHYQW6OTUFN5QS325VZQ3V26G65ANCNFSM57TKA34Q . You are receiving this because you were mentioned.Message ID: @.***>

[radu-cs]

Salut @guillaume-chervet , So here it is the ID Token and under it the ID Token Payload (both heavily edited). I hope that helps somehow.

Another info is that I only see the https://provider-url/userinfo call in the network tab. The https://provider-url/token is not visible at any time.

[guillaume-chervet]

hi @radu-cs, what I need is your first /token the body of the response (with the access_token) (before it has been catched by the ServiceWorker) If you want I can set up a Teams meeting. what is your email? (to invite you)

[radu-cs]

Hi @guillaume-chervet , Thank you for the offer (I really appreciate it) but I need to talk first with the team leader if I'm allowed to do this.

We use in production the latest v3 and this is just on the side to prepare for the migration later on.

I'll get back to you in ~2 weeks when we can plan some time for the migration.

Thank you once again for your support!

PS. It seems that the access token call is never exposed. The Service worker kicks in from the start.

Just in case here is my configuration:

const appURL = window.location.origin

const configuration = {
  accessTokenExpiringNotificationTime: '100',
  authority: process.env.REACT_APP_OIDC_AUTHORITY,
  client_id: process.env.REACT_APP_OIDC_CLIENT_ID,
  redirect_uri: `${appURL}/authentication/callback`,
  refresh_time_before_tokens_expiration_in_second: 60,
  resource: process.env.REACT_APP_OIDC_RESOURCE,
  scope: 'openid profile email phone api offline_access',
  service_worker_only: false,
  service_worker_relative_url:'/OidcServiceWorker.js',
  silent_redirect_uri: `${appURL}/authentication/silent_callback`,
  // monitor_session: true,
  // storage: sessionStorage,
}
export default configuration

[guillaume-chervet]

Hi @radu-cs , thank you for the feedback. Your configuration seem good. In the v3 did you use the ServiceWorker mode ?

You may see the real Tokens in your "request" tab into the console like in my screen upper. (it should display information before Service Worker and After Service Worker)

[radu-cs]

In v3 we are not using the Service Worker mode. And once again it seems that it is a specific browser problem. In Firefox there is a call for the token (but only one) which has the access_token obfuscated.

In Edge there are two calls for the token. First one has the access_token obfuscated, the second one it shows in clear.

But the Front End doesn't display the data and also the API call gets 401.

Also what I can get from this investigation is that the access_token used in v6 is way shorter than the one used in v3 (see screenshot).

[guillaume-chervet]

Thank you again @radu-cs for all your informations.

Did you tried to remove the use of the service worker ?

const configuration = {
  accessTokenExpiringNotificationTime: '100',
  authority: process.env.REACT_APP_OIDC_AUTHORITY,
  client_id: process.env.REACT_APP_OIDC_CLIENT_ID,
  redirect_uri: `${appURL}/authentication/callback`,
  refresh_time_before_tokens_expiration_in_second: 60,
  resource: process.env.REACT_APP_OIDC_RESOURCE,
  scope: 'openid profile email phone api offline_access',
  service_worker_only: false,
  //service_worker_relative_url:'/OidcServiceWorker.js',
  silent_redirect_uri: `${appURL}/authentication/silent_callback`
}

Do not forget to uninstall the Service Worker manually.

Did you change of OIDC server between v3 en v6 ? your access token come from OIDC server and should be the same size. It is very strange.

[radu-cs]

I just tried without the Service Worker. Now the token is showed in the front end but it is shorter than it is in v3 and also accessTokenPayload is null.

The Provider is the same for both instances.

In v3 to get the token for placing a call we use the following code:

const { oidcUser } = useReactOidc()

// create the fetch headers and options
const fetchOptions = (accessToken) => {
  const myHeaders = new window.Headers()
  myHeaders.append('Authorization', `Bearer ${accessToken}`)
  myHeaders.append('Content-Type', 'application/json')
  const requestOptions = {
    method: 'GET',
    headers: myHeaders,
    redirect: 'follow'
  }

  return requestOptions
}

// Place the API call
const fetchData = async () => {
  const res = await window.fetch(
    `${process.env.REACT_APP_API_URL}/apiEndPoint`,
    fetchOptions(oidcUser.access_token)
  )
...
}

[guillaume-chervet]

@radu-cs ,

if you are using the same configuration (client_id, etc.) with the v3, you have a obtain token ? I really do not know how it is possible :/

[radu-cs]

Yes all is the same. We'll get back to investigating it in ~2 weeks. Thank you once again and have a nice weekend! 🙂

[guillaume-chervet]

Have a nice week @radu-cs ^^

[robinsmedberg]

I'm also running into this exact issue. Disabling the serviceWorker also returns an error.

[guillaume-chervet]

hi @robinsmedberg ,

thank you for the feedback. i just fix the bug you have detected.

Does it work now for you whithout service worker?

[robinsmedberg]

Fetch works without the service worker.

I’m a bit worried about the effect of the failing initSession though.

[guillaume-chervet]

It is my faut, i am very sorry.

If you ré activate service worker does it works @robinsmedberg ? Which is your oidc server name? (To reproduce it)

[robinsmedberg]

No, same error when reactivating service worker. Oidc Server Name? Do you mean like Keycloak?

[guillaume-chervet]

yes, like keycloak :)

ACCESS_TOKEN_SECURED_... is normal, the expected behavior is to configure OidcTrustedDomain.js to add your api url and the service worker will inject automaticaly the correct token.

The correct access_token shoulb be visible here :

[robinsmedberg]

I'm terribly sorry (and embarrassed), I had the wrong url in trusted domains... It works now

[guillaume-chervet]

Thank you @robinsmedberg for the feedback. It is a good news. It appends to every developer :p

[radu-cs]

Salut @guillaume-chervet,

I have ~~good~~ some news regarding our use case. To be able to use the extended Access Token (the one with ~858 chars long) we needed to add to the configuration the following line:

userinfo_endpoint: null,

The Service worker does it's job with out problems (renewing works and the sensitive data is not seen in clear on the front end).

Now fetching using the useOidcFetch hook works as expected but the useOidcUser hook returns the oidcUser as null.

The inconvenient is that now we need to use the ID Token payload to get to the user information (not really a big deal though).

Although what I described above is working every time in Edge, in Firefox sometimes the user info call succeeds and the fetch breaks because the Access Token is reverted to the shortened form of ~43 chars and the user info shows up in front end.

[guillaume-chervet]

Hi @radu-cs, Thank you very much for your feedback. I am not sure to understand your problem. How do you retrieve user information if you set it to null? Are you doing a fetch manually ?

I am not sure to understand you problem with token length. Do you have sample with false data?

[radu-cs]

Salut @guillaume-chervet,

To better explain I will attach two screenshots.

One is taken from Firefox Developer Edition v105.0b9 and the other from Microsoft Edge v105.0.1343.33.

The Firefox one is here:

As you can see something is not quite right above, when comparing with the following screen shot from Edge:

Both browsers are loading the app using the same logged in user from localhost.

Later Edit: It seems that after a while the same behavior happens in Edge too (meaning the user info is showed by the useOidcUser() hook but the rest of the hooks loose the ability to work as expected).

[guillaume-chervet]

hi @radu-cs , this is a very strange behavior.

Do you have an error in the console or something that can help?

Does you Oidc provider is stable (for exemple under development)? DO you have a proxy or something that can modify you HTTP request?

[radu-cs]

Salut @guillaume-chervet,

The OIDC provider is stable and in production. There is no proxy involved.

I will keep it under observation and I will paste the console logs when this behavior happens.

[guillaume-chervet]

Salut @radu-cs ,

I need more information in order to help you. Does you oids server use state property or somehing else to change the user behavior?

With the old v3 of react oidc you have the good behavior?

Is it possible to make a call via team or something else?

[radu-cs]

Salut @guillaume-chervet, Sorry that I didn't make it yesterday with the logs.

Here they are in a private repository that I invited you to (I edited sensitive data). LE. Deleted

In the future I'll use this repository to post logs.

Thank you for your help!