Refreshing Tokens for Data Sources

[amrap030]

Hello together,

it seems, that the configuration for data sources assumes, that a JWT Token in the authorization header has no expiration time. From my understanding, a JWT or in particular Access Tokens, that are used for authentication/authorization purposes, are considered to be sensitive and therefore should mitigate misusage, for example via short expiration times.

In fact, I am using Keycloak as my Authorization Server for authentication, where I also store users, groups, roles etc. I would like to use this information for policy decisions in OPA and want to use it as a data source in OPAL. To be able to fetch this data, you have to firstly obtain a JWT Token, for example via Client Credentials Flow with a Service Account against the Keycloak Authorization Server. In addition, in Keycloak you have to set an expiration date for JWT's, so to constantly be able to fetch data from Keycloak, you have to refresh expired tokens.

While I think you could just set the expiration date in Keycloak to something like "100000000000000000" days, I also think this is bad practice and it unfortunately not only affects the service account, but also the JWT Tokens for authenticated users. If it would only affect the service account, this would still be bad practice for me, but would be okay, because service accounts only communicate via backends (machine to machine communication) and can't accidentally reveal JWT Tokens. I also think, if I would redeploy the Authorization Server, all previously issued JWT's are not valid anymore, so even in this scenario I would need to update the Bearer Token in the data source config.

What are your thoughts on this situation?

[asafc]

Hi @amrap030, great questions! Let's tackle them one-by-one.

TL;DR

OPAL cannot currently support refresh tokens natively, however there is a solution - redirecting to external data sources.

1. For dynamic data updates - there is no need for refresh tokens - you may use short lived tokens with no issue.
2. For data updates initiated by the client, the server will decide on the contents of the updates based on OPAL_DATA_CONFIG_SOURCES which is encoded into an env var - therefore you must use long lived tokens - which violates your requirement. However, OPAL_DATA_CONFIG_SOURCES can redirect to an external data source served by your backend, and this backend can generate short lived tokens on the fly.
3. We might add refresh token support if its something that you find important - let's have a discussion about it :)

Continue reading for detailed explanations.

Q: In which flows does OPAL uses tokens to fetch data?

If the sources of data are protected by authentication, OPAL client can fetch data using a token (a JWT, or any other token). You may also use user-password or any other authentication mechanism by writing custom data fetchers.

Tokens are relevant in two distinct cases:

1) Data updates initiated/requested by OPAL client (OPAL_DATA_CONFIG_SOURCES)

There are two cases in which the OPAL client, and not the OPAL server, will be the one initiating a data update:

1. During startup - when there is no data saved in OPA cache, OPAL client will ask the server what data sources to fetch (the "entire picture" of data - not a delta).
2. After disconnect between OPAL client and server - If for any reason, and for however short a time, the server and client are disconnected (i.e: server is down, network issue, etc).

Either during startup or after disconnect - the client will ask the server where to find the data, and the server will reply with a list of DataSourceEntry objects - each one is a directive to fetch some data and put it in OPA cache. The server stores this configuration in env var OPAL_DATA_CONFIG_SOURCES.

2) Dynamic data updates

When your data sources are changed, you can notify the OPAL client to refetch the data by using the updates api.

A few things to understand about this:

• It is your responsibility to track your dynamic data sources and monitor them for changes. OPAL is simply a conduit through which you can trigger an update that will reliably propagate across all your policy agents. Think about OPAL as a smart pipe to push updates. You still need to be the one pushing the updates, the pipe won't do it for you :)
• Dynamic updates are also formatted as DataSourceEntries, however there is no need to pass an entry for the entire data - only for the data that changed. Each entry contains instructions what document path (i.e: document in OPA cache) to override.

I wrote about it more extensively here.

Q: Can OPAL support refresh tokens? Should it support refresh tokens?

The question to this answer differs for each type of data update. We'll start with the easy case.

Refresh tokens for dynamic data updates - not required!

For dynamic updates, there is no need for long-lived tokens. The updates are initiated by your backend (as mentioned above - your responsibility, OPAL is just a conduit), and you can generate a short-lived token on the fly and pass it as part of the update message sent to OPAL updates api.

Example: a user was invited into your app and was assigned a role - the microservice responsible for this role assignment will generate a token on the fly by calling keycloak, and will then use OPAL updates API to notify all relevant clients about this update.

The update message will include:

• The url to get the data about this role assignment.
• The newly generated token (short lived token generated on the fly by keycloak)
• The path to the OPA document you want to override.
• A topic targeting the relevant OPAL clients.

Refresh tokens for client-initiated data updates (served from OPAL_DATA_CONFIG_SOURCES)

If you set the env var OPAL_DATA_CONFIG_SOURCES with static configuration, you must currently use long-lived tokens.

We might be able to support short-lived tokens by adding support for refresh tokens, in which case every time the server is asked to provide the data sources - it checks for the validity of token and can initiate token update. This feature does not currently exist - let's talk about it and see if it makes sense.

However, there is a solution in the current version of OPAL - redirecting to an external data source (shown below).

Q: How does redirection to external data sources work?

Observe the following configuration value for OPAL_DATA_CONFIG_SOURCES:

OPAL_DATA_CONFIG_SOURCES={"external_source_url":"http://mybackend.com/opalsources"}

When fetching the data sources from the server, the client will issue an HTTP GET request to this API endpoint, e.g if opal server is located at opal.authorizon.com, the request will be:

GET https://opal.authorizon.com/data/config

if external_source_url is configured as above, OPAL server will return an HTTP 307 REDIRECT response, redirecting to this url:

http://mybackend.com/opalsources?token=CLIENT_TOKEN

where CLIENT_TOKEN is the JWT token the OPAL client uses to authenticate against the OPAL server.

Your backend located at http://mybackend.com can then talk to keycloak to generate the JWT token for the data source entries in the response on the fly.

Your endpoint code for /opalsources will do the following:

1. for each data source entry - talk to keycloak and generate a valid short-lived JWT, assume the generated JWT is jwt1
2. your response can then be something like this:

{
    "entries": [
        {"url":"https://api.yourservice.com/v1/roles","topics":["policy_data"], "dst_path": "roles", "headers": {"Authorization": "jwt1"}},          
        ...
    ]
}

Hope this is clear enough, feel free to ask follow-up questions.