OIDC - Add support for logout and token revocation [THREESCALE-312]

[tmogi001]

Hi,

I create OpenID Connect logout and token revocation feature.THREESCALE-312

specs are below

add /oidc/logout endpoint

• delete access token from cache
• add acccess token to the "revoked token cache"
• send POST request to the end_session_endpoint of IdP

When the client send a POST request to the logout endpoint with
header : bearer with access token
body : refresh_token=<refresh token>
then delete access token from the cache and logout from IdP.

add token introspection feature

• only execute when the access_token is not cached.
• add "APICAST_TOKEN_INTROSPECTION_ENABLED" config to enable this feature

This feature covers the requests 1) token is not cached, 2) token is not expire and 3) token was revoked at IdP.

[octobot]

	1 Error
🚫	Please include a CHANGELOG entry. You can find it at CHANGELOG.md.

	1 Message
📖	Note, we hard-wrap at 80 chars and use 2 spaces after the last line.

Generated by 🚫 Danger

[mikz]

@tmogi001 Well done! It is well structured, has tests, 👍 . Sorry it took me so long to take a look at it.

I'm not sure about the design of this feature. We made OIDC to remove endpoints from the gateway and allow it to be stateless.
This approach would require some shared store for the token cache between gateways. Otherwise revoking it on one gateway would not revoke it on others.

If this needs some stronger consistency than just TTL, then it should be stateless in my opinion.
Doing call to the IDP to verify if the key is still valid would have to be done on every request to the gateway.

I'd like to open the discussion about this and hear what requirements drove it doing it this way.

[tmogi001]

@mikz Thank you for looking my PR.
I agree with your opinion. The gateway should be stateless. I should care about multiple gateway environments.I will remove logout endpoint and revoke_credentials method.

And I will fix to execute Token Introspection at every request to the gateway, if "APICAST_TOKEN_INTROSPECTION_ENABLED" is true. I think this option will allow users to choose between "performance" or "security".

[mikz]

@tmogi001 Let me iterate a bit.

Another point I forgot is that now the gateway has access to the IDP as authorized Service Account.
I don't think that is wise as that same Service Account can manage all clients. And gateway definitely should not have access to that in my opinion. But there is just one setting in the UI, so I understand that is a problem.

I think we need a definition of what are we trying to solve before actually committing to the implementation.

Are you sure 1:1 mapping for API calls to the IDP is viable way forward? And when introducing cache it basically behaves the same as forcing to rotate the token every N seconds.

[tmogi001]

@mikz I'm sorry I didn't show our problem clearly.

We must meet the requirements of financial API.　(http://openid.net/specs/openid-financial-api-part-1.html)

In FAPI specifications, 6.2.1 Protected resources provisions shows that resource server with the FAPI endpoints "shall verify that the access token is not expired nor revoked". We use gateway as a resource server, so we must meet this requirement.

But gateway can't verify the token is revoked without Token Introspection.

And in my opinion, API calls to IdP rarely fail.
If IdP goes down, we can not keep the whole system secure, so IdP must have high reliability.

In such as a high-security system, the value of gateway is "Security".

[mikz]

@tmogi001 that is very useful resource, thank you.

I think gateway is just Relaying Party, not the Resource Server. But it is possible I'm not understanding the spec and what Relaying Party is.
Otherwise there would be additional requirements that the gateway can't possibly comply with (like verify scope, always return utf-8).

But ok, I agree it could be useful for the gateway to verify the token is revoked.

The gateway has to handle network errors to the IDP. What happens when the gateway can't connect to the IDP ? Should it use last known state? I'm worried this will start exploding in complexity once under production load and network conditions.

Also I really don't want to give the gateway the same Service Account as is used in for managing clients via Zync. This access has manage-clients role that seems too elevated for this purpose.

What are the ways to verify Access Token with least permissions? I guess the token itself can't be used to authorize the call, right?

Also I'll need to do some benchmark of the token introspection API to get some numbers on its performance.

On another topic.
I'm working on having multiple policies active at the same time (#450) and this might be a good candidate to try it with. Adding OIDC Token Introspection as another policy in the chain. But It is still quite early for that. I hope to make some example soon. I think it would drive the API changes (like having another module for the introspection and http calls). But that would be just moving code around.

[tmogi001]

But ok, I agree it could be useful for the gateway to verify the token is revoked.

Thank you for understanding!

The gateway has to handle network errors to the IDP. What happens when the gateway can't connect to the IDP ? Should it use last known state? I'm worried this will start exploding in complexity once under production load and network conditions.

In the system where OpenID connect is required, IDP is critical. When the gateway cannot connect to the IDP, gateway must stop API calls to keep security. To avoid that, HA of IDP and network are required.

Also I really don't want to give the gateway the same Service Account as is used in for managing clients via Zync. This access has manage-clients role that seems too elevated for this purpose.

I understand your concern. I think we have two choices.

1. Create new client for token introspection.
   Pros: Least privilege for token introspection
   Cons: Additional client id and secrets have to be managed.
2. Use manage-clients role also for token introspection
   Pros: Additional configuration is not required
   Cons: Elevated access rights

Personally, I think 1 is better.

On another topic.
I'm working on having multiple policies active at the same time (#450) and this might be a good candidate to try it with.

Thank you for information, I will check it later.

[lucamaf]

what's the status on this @mikz ? Are we then trying to add this as a Policy? Would we go down path 1 suggested by @tmogi001 ?

[mikz]

@lucamaf status is the same as you can see in this issue. "We" are not doing anything.

[tmogi001]

Sorry to leave this request for a long time.
Currently I am creating "Token Introspection" features as a Policy, and planning to make a new PR by the end of February.

[mikz]

@tmogi001 perfect! Feel free to reach out if you need any help with custom policies.

We have a WIP PR that migrates our policies we run in the Cloud Hosted deployment on SaaS: 3scale/apicast-cloud-hosted#1
Once that is merged it should show clear picture how to embed policies inside custom image and how to develop and test them in isolation.

Also with #495 it should be possible to hook into JWT before the authorization (in the rewrite phase) is sent to 3scale backend (access phase).

[mikz]

Closing in favour of really great #619 👍