Skip to content

Commit

Permalink
Some tidying up
Browse files Browse the repository at this point in the history
Signed-off-by: Anders Eknert <anders@styra.com>
  • Loading branch information
anderseknert committed Nov 5, 2024
1 parent 0365dc5 commit 0e524a2
Showing 1 changed file with 7 additions and 10 deletions.
17 changes: 7 additions & 10 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,9 +30,7 @@ If your need to verify tokens without these constraints, use the
The following steps assume that your JWT's are issued by an identity server supporting either OAuth 2.0 or OpenID
Connect discovery endpoints. For other options, see the [Configuration](#configuration) section below.

#### 1. Create a configuration file for `lib.jwt` in the root of your bundle:

**data.yaml (or data.json)**
#### 1. Create a configuration file (data.yaml or data.json) for `lib.jwt` in the root of your bundle:

```yaml
lib:
Expand All @@ -55,8 +53,6 @@ opa build --bundle app lib

#### 3. Write a policy that uses the `lib.jwt` library:

**policy.rego**

```rego
package app.authz
Expand All @@ -80,11 +76,12 @@ allow if {

But wait, where's the code to verify the token? That's all handled by the library! How?

1. The library will retrieve the JWT in the input document at the path provided by `input_path_jwt`
2. The `iss` claim in the token will be checked against the allowed issuers, and if it matches, will
fetch the public keys from the issuer's OAuth/OIDC metadata endpoint, and use them to verify the token
3. On successful verification, the claims from the token will be available in the `jwt` object under `claims`,
and in case of errors (including other constraints failing), they will predictably be available under `errors`.
1. The library retrieves the JWT in the `input` document at the path provided by `input_path_jwt`
2. The `iss` claim in the token is be checked against the `allowed_issuers`, and if it matches, the library
fetches the public keys from the issuer's OAuth/OIDC metadata endpoint — and use them to verify the token
3. On successful verification, the claims from the token are made be available in the `jwt` object under `claims`,
and in case of errors (including other constraints failing), the error messages ae predictably made available
under `errors`

**Tip:** If you're unsure about the issuer's discovery capabilities, check the `iss` claim in the token for the HTTPS
URL of the issuer. Take this URL and append `/.well-known/openid-configuration` to get its OIDC metadata endpoint, or
Expand Down

0 comments on commit 0e524a2

Please sign in to comment.