{"id":57,"date":"2025-03-30T10:31:32","date_gmt":"2025-03-30T10:31:32","guid":{"rendered":"https:\/\/www.familie-kleinman.nl\/brain\/?p=57"},"modified":"2025-03-31T08:38:19","modified_gmt":"2025-03-31T08:38:19","slug":"oracle-owsm-and-jwt-token-handling","status":"publish","type":"post","link":"https:\/\/www.familie-kleinman.nl\/brain\/index.php\/2025\/03\/30\/oracle-owsm-and-jwt-token-handling\/","title":{"rendered":"Oracle OWSM and JWT token handling"},"content":{"rendered":"

I’ll be trying to post several times a week during these first couple of weeks to get some content going. A blog without posts is, well… basically just a placeholder, right? And I’m also trying to stay true to one of the words in the subtitle: commitment<\/em>. I started this blog for a reason, after all.<\/p>\n

So, back on the topic of the day.<\/p>\n

In my line of work I do a lot with Oracle SOA\/Middleware and Oracle Service Bus (OSB) and its related products. And because security is always an issue, making your software more secure is always a priority. An option is to secure your flows with JWT tokens handed out by a third party product. Handling this can be done with Oracle Web Services Manager, or OWSM for short. OWSM is part of the Oracle SOA\/Middleware software stack, so it should be quite easy to use, right?<\/p>\n

The biggest problem is documentation, and not in the way you think. Oracle is very good at documenting their products \u2014 so good, in fact, that finding what you actually need becomes almost impossible. So the next step is to look for others who’ve run into the same problem and use their experience as a reference. We found this blog: https:\/\/planetofsolutions.wordpress.com\/2020\/04\/22\/how-to-validate-oauth2-token-in-oracle-service-bus\/<\/a><\/p>\n

The biggest problem with using blog posts is that the original author has the context how to interpret the text and the images used. And that context is exactly what made my work a lot harder. So, in this post, I\u2019ll try to clarify all the difficult parts \u2014 and hopefully not step into the same context trap.<\/p>\n

It boils down to these two steps.<\/p>\n

    \n
  1. Attach an OWSM policy to your OSB .proxy ( oracle\/http_jwt_token_service_policy<\/strong> )<\/li>\n
  2. Configure OWSM to verify the integrity of the JWT token that is sent as an HTTP Authorization header in a request to a OSB proxy<\/li>\n<\/ol>\n

    Step 1 is the easy part, step 2 is where the configuration nightmare begins when you don’t know exactly what you’re doing.<\/p>\n

    The secret lies in understanding what OWSM actually does<\/em> before you even start configuring it. Once you know what\u2019s happening under the hood, it becomes much easier to explain where<\/em> it needs to be configured. And even more important: how those different parts of the configuration interact with each other!<\/p>\n

    JWT<\/h1>\n

    A JSON Web Token (JWT) consists of three distinct parts.<\/p>\n

      \n
    1. Header<\/li>\n
    2. Payload<\/li>\n
    3. Signature<\/li>\n<\/ol>\n

      For the purpose of this blog post, parts 3 and 2 are the most important. And yes \u2014 I\u2019ll explain in a minute why I\u2019m listing part 3 before<\/em> part 2.<\/p>\n

      Part 1, is the token valid?<\/h2>\n

      This is where part 3, the signature<\/strong>, of the token comes into play. The very first thing OWSM needs to do is verify that the signature is valid. A JWT is signed using a private key, and to verify it, OWSM needs the public certificate<\/strong> \u2014 or more precisely, the entire public certificate chain<\/strong> \u2014 to be imported and available.<\/p>\n

      Part 2, is the issuer trusted?<\/h2>\n

      Great \u2014 the signature is valid. Now what? This is where part 2<\/strong>, the payload<\/strong>, comes into play. OWSM somehow needs to know whether the issuer of the JWT token can actually be trusted<\/em>.<\/p>\n

      This is typically done by validating the CN<\/strong> (Common Name) or DN<\/strong> (Distinguished Name) from the public certificate used to sign the token. And this is where things can start to get a little confusing… But don\u2019t worry \u2014 I\u2019ll get back to this in more detail soon.<\/p>\n

      Part 3, is the token expired?<\/h2>\n

      At this point, OWSM starts looking into the payload<\/strong> itself. The first field it checks is the \"exp\"<\/code> claim.<\/p>\n

      This field contains the expiration time<\/strong> of the token, expressed in Unix Epoch time<\/strong> \u2014 the number of seconds since January 1, 1970. If the current time is greater than this value, the token is considered expired and will be rejected.<\/p>\n

      Part 4, is the audience trusted<\/h2>\n

      OWSM will now check the \"aud\"<\/code> field inside the payload.<\/strong><\/p>\n

      This field tells you who<\/strong> the token is intended for. In other words: “This token was issued specifically for application X.”\u00a0<\/em>OWSM (or any secure service) can be configured to check whether the \"aud\"<\/code> value matches the expected identifier of the service. If it doesn\u2019t match, the token is considered invalid<\/strong> \u2014 even if the signature is correct and the token hasn\u2019t expired.<\/p>\n

      This is a useful way to prevent token misuse \u2014 for example, if someone tries to use a token meant for Service A<\/em> to access Service B<\/em>.<\/p>\n

      But there\u2019s a huge catch with this.<\/strong>
      (See the note at the bottom of this blog post.)<\/em><\/p>\n

      It means we somehow need to maintain a list of trusted audiences<\/strong> somewhere in the OWSM configuration \u2014 and that\u2019s where things start to get tricky.<\/p>\n

      Part 5, subject check<\/h2>\n

      And this is where Oracle deviates from the standard.<\/strong><\/p>\n

      According to the JWT specification, there\u2019s an optional field called \"sub\"<\/code> \u2014 short for subject<\/strong>. It\u2019s meant to identify the principal (usually the user or system) that the token refers to.<\/p>\n

      Optional<\/strong>, as in: nice to have, but not required. Except\u2026 Oracle made it mandatory<\/p>\n

      At least in the version of OWSM we use, the \"sub\"<\/code> field is treated as mandatory<\/strong> \u2014 and this wasn\u2019t documented anywhere<\/strong> at the time.\u00a0 By now you can find a support document on Oracle Support.<\/p>\n

      Let\u2019s just say: that one took us a while to figure out.<\/p>\n

      This does mean that we need to configure the subject somewhere!<\/p>\n

      Summary #1 – OWSM validation flow<\/h1>\n

      OWSM will go through the following five validation layers:<\/p>\n

        \n
      1. \n

        Is the token valid?<\/strong>
        \u2003\u2192 Signature check using the public key.<\/p>\n<\/li>\n

      2. \n

        Is the issuer trusted?<\/strong>
        \u2003\u2192 Based on the certificate\u2019s CN\/DN.<\/p>\n<\/li>\n

      3. \n

        Is the token expired?<\/strong>
        \u2003\u2192 Checked via the \"exp\"<\/code> (expiration) claim.<\/p>\n<\/li>\n

      4. \n

        Is the audience trusted?<\/strong>
        \u2003\u2192 Checked via the \"aud\"<\/code> claim, if configured.<\/p>\n<\/li>\n

      5. \n

        Is the subject trusted?<\/strong>
        \u2003\u2192 The \"sub\"<\/code> claim must be present \u2014 and is it configured.<\/p>\n<\/li>\n<\/ol>\n

        Configuration<\/h1>\n

        Prerequisites<\/h2>\n