Best way to have 1 front controller for 2 okta applications

I created one front controller (for a REST API) for my okta application. I followed this article and it works fine for machine-to-machine communications. The authenticate() function in my index.php looks like this:

function authenticate() {
  try {
    switch(true) {
    case array_key_exists('HTTP_AUTHORIZATION', $_SERVER):
      $authHeader = $_SERVER['HTTP_AUTHORIZATION'];
    case array_key_exists('Authorization', $_SERVER):
      $authHeader = $_SERVER['Authorization'];
      $authHeader = null;

    preg_match('/Bearer\s(\S+)/', $authHeader, $matches);
    if (!isset($matches[1]))
      throw new \Exception('No Bearer Token');

    $jwtVerifier = (new \Okta\JwtVerifier\JwtVerifierBuilder())
    return $jwtVerifier->verify($matches[1]);
  } catch (\Exception $e) {
    return false;

Notice that my jwtVerifier sets the client ID getting the information from my local .env file.

Now I added a second application, to deal with a web-app client, doing simple javascript fetch in a browser. This second application added in my Okta account is of the type SPA / Native, but I want (after I get Okta access token) to consume my REST API being validated by my index.php.

Initially I had not realized that it was not working because the client ID in my index.php authenticate() function is for the API Services application (gotten from my .env file by my php application). I manually changed the ID in my index.php to be the one from my SPA / Native application and then it works.

So, my question is… to make my authenticate() function in my index.php work with both my regular clients (machine-to-machine) and my web client (browser), which have their own client ID, how should I send the client ID in my HTTP request to my index.php? It sounds like the client ID should be sent in a header, and in my index.php I parse that and set my jwtVerifier with that client ID (instead of getting it from .env file). If so, what is the best header to send this information? If sending it through the header is not appropriate, what is the recommended approach?

If you are receiving Okta access tokens, the token is base64 encoded, so you should be able to decode it, get the cid claim (client id), and then use that to initialize the JWT verifier and verify the signature, etc.

I checked the access token, it decodes to {"kid": "some random chars", "alg": "RS256"}gibberish..., the “kid” is not my client ID and it will fail because of the gibberish that comes after it… I tested sending the client ID with X-Request-ID header, and in my controller I get it to create the JWT. It is working just fine… but I read some articles saying that usually that field is used for IDs that are renewed with each connection (apparently that is what heroku does). But I’m not entirely sure… I hope someone sheds some light here…

The toke will be broken up into 3 parts

Try to see the 3 parts. When you decode you need to break up the 3 parts separated by a period ‘.’ and decode the payload part.

Awesome… I hadn’t realized that this was what the access token was composed of. I decoded the second part, turned into an object, got the “cid” and use that to prepare my JwtVerifier. Thanks a lot

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.