topic Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained in Application Development and Automation Discussions

SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

qmacro — Mon, 28 Aug 2023 06:43:04 GMT

(Check out the SAP Developer Challenge - APIs blog post for everything you need to know about the challenge to which this task relates!)

You're almost ready to call the API endpoint to examine the details of the directory you created back in Task 7. But as we're going deliberately slowly and surely, let's take some time in this task to stare at the access token itself for a few minutes, to see what we can discover.

Background

In the previous task you obtained an access token, by completing the flow described by the OAuth Resource Owner Password Credentials grant type. The access token was made available to you in a JSON object which contained not only the access token itself, but other values. Here's that example from the previous task, with the expires_in property added back in:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "bearer...",
  "id_token": "eyJhbGciOiJSUzI1NiIs...",
  "refresh_token": "e72b61a9a9304dde963e...",
  "expires_in": 43199,
  "scope": "cis-central!b14.glob...",
  "jti": "579fea14a1cf47d7ab9e..."
}

One of the values also provided is scope, which contains a whitespace separated list of scopes. If you were to parse the value, you'd see the list. Here's one way to do that (truncating the list to the first 10 scope items), assuming the JSON object representing the token data is in a file called tokendata.json:

jq '.scope|split(" ")[:10]' tokendata.json

This would produce:

[
  "cis-central!b14.global-account.subaccount.update",
  "cis-central!b14.global-account.update",
  "user_attributes",
  "cis-central!b14.global-account.subaccount.delete",
  "cis-central!b14.global-account.subaccount.read",
  "cis-central!b14.job.read",
  "cis-central!b14.catalog.product.update",
  "cis-central!b14.catalog.product.delete",
  "cis-central!b14.global-account.account-directory.create",
  "cis-central!b14.directory.entitlement.update"
]

This metadata, data about the access token, essentially, is useful to us to have. But what's more interesting is how this scope information is conveyed in the actual call to the API endpoint.

It's specifically the value of the access_token property from the JSON object that is sent in the Authorization header of the HTTP request made, as you learned about in Task 9. The other values in the JSON object (the id_token, refresh_token, expires_in values, and so on) don't go anywhere, they're just for us, the consumer, to use in managing our use of that access token (including knowing when it will expire and requesting a refresh).

So the scope information for this access token appears to be conveyed in a property (scope) that doesn't get sent to the resource server. How does the server then know whether to respond with the requested information or not?

To answer this question, we're going to go on a bit of a digression in this task.

So.

Have you ever wondered about the value of the access token itself? It's a very large, opaque string. In fact, how long is it?

jq -r '"\(.access_token|length) bytes"' tokendata.json

Pretty long!

3912 bytes

Surely there must be a reason for something so large?

The anatomy of the access token

Yes. It's actually a JSON Web Token, or JWT (often pronounced "jot"). A JWT contains structured data, which is fascinating to peek at. And that's what you're going to do in this task.

First of all, it's worth knowing that the content of a JWT is organized into different sections, including:

Header
Payload
Signature

The Header contains a small amount of data about the JWT itself, and consists of values for a series of well-defined (in RFC7515) parameters, the names of which are all three characters in length (to keep things short). Examples are "alg" which identifies the algorithm used to secure the data, "jku", the value of which is a URL that points to a JSON Web Key Set used in the digital signature, and "typ" which conveys the type of content it is.

The Payload section of the JWT is where the data that's most interesting to us lives, or rather most interesting to the server that will handle our requests. It's where the scopes (that we saw earlier) are stored, amongst many other details.

The Signature is essentially a signed checksum of the entire contents.

So the answer to the question above is that the server knows how to respond to requests because there's enough information passed inside the access token (being in the form of a JWT), including a list of scopes that the token conveys for the consumer, for it to decide.

Your task

Your task is to examine the contents of the access token, by treating it for what it is, i.e. a JWT. You should take information from the Header, and information from the Payload, and combine it into a value that you should send to the hash service, and then put the resulting hash into a reply to this thread, as always, and as described in Task 0.

What specifically is that information?

from the Header, you should take the value of the "alg" and "typ" parameters
from the Payload, you should count the number of scopes conveyed

You should then combine those three pieces of information like this, using colons as separators:

<value-of-alg>:<value-of-typ>:<number-of-scopes>

Let's look at the partial contents of an imaginary (but typical) JWT in this context, to illustrate. This illustration assumes that the access token JSON data (such as you retrieved in the previous task, Task 10) is in a file called tokendata.json. This illustration is also based on using the jwt-cli package, and the command line tool it provides, as described in the "Hints and tips" section below.

So, to pick out the value of the access token (from the access_token property in the JSON object in tokendata.json), and then to treat that access token value for what it is, i.e. a JWT, and ask for the JWT to be expanded into its component parts, you'd do something like this (note the --output=json option to produce nicely machine-parseable output!):

jq -r .access_token tokendata.json | jwt --output=json

What is emitted is something like this (heavily redacted, for brevity, and with some values elided while others are replaced, for the illustration):

{
  "header": {
    "alg": "ABCDE",
    "jku": "https://c2d7b642trial-ga.authentication.eu10.hana.ondemand.com/token_keys",
    "kid": "default-jwt-key-1281344942",
    "typ": "XYZ",
    "jid": "iaVmTleRBCIVnVE7veQ9opMtlHnk+3DvKWWsjpsm542="
  },
  "payload": {
    "jti": "579fea14a1cf47d7ab9e5bf4c9d15d42",
    "ext_attr": {
      "enhancer": "XSUAA",
      "globalaccountid": "7da58aab-6c60-4492-a95b-b1ed3139e242",
      "zdn": "c2d7b642-ga",
      "serviceinstanceid": "f118abbb-b387-41b1-970f-bf4f0309c142"
    },
    "xs.system.attributes": {
      "xs.rolecollections": [
        "Global Account Administrator"
      ]
    },
    "given_name": "DJ",
    "xs.user.attributes": {},
    "family_name": "Adams",
    "sub": "965a393a-dc96-422f-87ac-9f3d8bb25142",
    "scope": [
      "cis-central!b14.global-account.subaccount.update",
      "cis-central!b14.global-account.update",
      "...another 39 scopes...",
      "cis-central!b14.global-account.subaccount.create"
    ],
    "client_id": "sb-ut-f86082c9-7fbf-4e1e-8310-f5d018dab542-clone!b254742|cis-central!b14",
    "cid": "sb-ut-f86082c9-7fbf-4e1e-8310-f5d018dab542-clone!b254742|cis-central!b14",
    "azp": "sb-ut-f86082c9-7fbf-4e1e-8310-f5d018dab542-clone!b254742|cis-central!b14",
    "grant_type": "password",
    "user_id": "965a393a-dc96-422f-87ac-9f3d8bb25142",
    "origin": "sap.default",
    "iat": 1692693022,
    "exp": 1692736222,
    "...": "..."
  },
  "signature": "ZVe_aqyLAyXwToCvG...",
  "input": "eyJhbGciOiJSUzI1NiIsI..."
}

So the three values in the result you should construct, thus:

<value-of-alg>:<value-of-typ>:<number-of-scopes>

should be, in order:

<value-of-alg>: the value of the .header.alg property
<value-of-typ>: the value of the .header.typ property
<number-of-scopes>: the length of the array that is the value of the .payload.scope property

For example:

ABCDE:XYZ:42

Hints and tips

There are many tools and libraries with which JWT tokens can be parsed, even online facilities ... though you should think twice before sending authorization data to third party websites - it's better to use a tool that you have locally.

For tools to use locally, you might wish to check out the NPM package jwt-cli which, if you install it globally, will give you a command line tool called jwt.

It's one of my standard globally-installed NPM-based tools, which you can see here, via:

npm list --global

This emits:

/home/user/.npm-global/lib
+-- @sap/cds-dk@7.0.2
+-- @sap/generator-fiori@1.9.4
+-- @sapui5/generator-sapui5-templates@1.71.6
+-- @ui5/cli@3.1.1
+-- bash-language-server@4.9.1
+-- docsify-cli@4.4.4
+-- eslint@8.39.0
+-- fx@28.0.0
+-- http-server@14.1.1
+-- httpie@1.1.2
+-- jwt-cli@2.0.0
+-- lodash@4.17.21
+-- lorem-ipsum@2.0.8
+-- markdownlint-cli@0.34.0
+-- prettier@2.8.8
+-- ramda@0.29.0
+-- url-decode-encode-cli@2.1.0
+-- yarn@1.22.19
`-- yo@4.3.1

With the jwt tool, you can decode such JWT access tokens. And with jwt's --output=json option, it's even better!

For discussion

The expires_in property, that accompanies the access token returned, has an interesting value. It's 1 second less than 12 hours. Do you think that's deliberate? Calculated?

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

vladimirs_semikins — Mon, 28 Aug 2023 06:35:39 GMT

16f0aec1122dac8b7da8564df068bc8c4e26f56c949f944d264ef23cc31c3b26

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

vladimirs_semikins — Mon, 28 Aug 2023 06:38:45 GMT

I've used raycat plugin https://www.raycast.com/gdsmith/jwt-decoder to decode JWT token

Also, I never say "jot," but instead spell it as J-W-T. Thankfully, I'm not the only one who does this - https://www.youtube.com/watch?v=D2D9umQMKhA

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

qmacro — Mon, 28 Aug 2023 06:43:44 GMT

Haha, you're right. I've added the word "often" to the text, to suggest that not everyone does 🙂

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

harsh_itaverma — Mon, 28 Aug 2023 06:45:03 GMT

ec09383eb0242b8c3cff9ce4aef8a219dd6b2941314b44e1ba64b0b0db1b72e9

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

ajmaradiaga — Mon, 28 Aug 2023 06:56:38 GMT

5ba8c7208393835e1cf329cab9893f70a4603c1381c70090c70ccbeff046f666

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

ajmaradiaga — Mon, 28 Aug 2023 07:02:42 GMT

I used this to decode the JWT - https://github.com/mike-engel/jwt-cli

brew install mike-engel/jwt-cli/jwt-cli # Note that the command line for JWT will be a bit different than when using the npm package jq -r .access_token cis_access_token.json | jwt decode -j -

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

prachetas — Mon, 28 Aug 2023 07:43:06 GMT

c219a98398a34ee23da4a4f41e2596d9f802b9d07d73048b85a45ad33f16c19b

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

SandipAgarwalla — Mon, 28 Aug 2023 08:12:32 GMT

2aad754ea377922f55c2a729eef24c0796cda2115d35c75187f0dff537e73d8d

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

emiliocampo — Mon, 28 Aug 2023 08:20:38 GMT

d6b9a707cd27046564812042900385b19ce0afe50c47efb5a559349b5bfde8e8

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

tobiasz_h — Mon, 28 Aug 2023 08:57:47 GMT

c6c915af93f2cb45053bf7d7b7723e336fef38d76d87ecb37b2bb8f02c2ec210

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

kasch-code — Mon, 28 Aug 2023 09:03:26 GMT

2c5617d44946820f48299176762a43cf3e2c5289552d702295afccdd89f3f6b9

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

szeteng00 — Mon, 28 Aug 2023 09:18:25 GMT

5fc1973f8d4cc3e2e39a3755df52a2d93d83c7047d24f459288cf5958fb77511

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

choujiacheng — Mon, 28 Aug 2023 09:32:07 GMT

f0b52968defdd5dcbef3d6a77f530cfefa3d03a846afad6c451e5419f419b9c1

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

choujiacheng — Mon, 28 Aug 2023 09:36:02 GMT

It might be deliberate since the counter might start before the access token is sent to the user, of which the countdown has already begun, but this is speculation as I do not know the process of access tokens well.

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

qmacro — Mon, 28 Aug 2023 09:56:01 GMT

This is a good guess! On the one hand, it seems odd to me that this is a deliberate move (to subtract 1 second before sending the value in the response), but on the other hand, it makes sense.

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

Dan_Wroblewski — Mon, 28 Aug 2023 10:50:45 GMT

9047ad05fec9cc9f019fe6a2d6d42a830ceeed41655012c7fac880effefe3781

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

Tomas_Buryanek — Mon, 28 Aug 2023 11:03:37 GMT

e1c6cd6372b2f1c60672eba17388cdbc975a546c8a556b91ed00e7ba17dbc10c

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

ceedee666 — Mon, 28 Aug 2023 14:51:10 GMT

c5e4df13ad9dfc27d086bd00ab175e2741833e9f16148df21325d64224785b64

Re: SAP Developer Challenge - APIs - Task 11 - Examine the access token for scopes contained

ceedee666 — Mon, 28 Aug 2023 11:43:05 GMT

I struggled a lot today. Wasn't able to decode the token in Python. Still unclear way... 😔.

Furthermore I think something is wrong with my token as it only contains one scope.