Revoke and refresh token for Edge micro

Not applicable

Hi,

I am new to Edge micro. I see that the part4 of the tutorial talks about how to generate a token using edgemicro-auth proxies.

Question: Can the edgemicro-auth proxy be used for revoke and refresh token flows out of the box or do we need to customize

Thanks,

Jaskaran

Solved Solved
0 4 506
1 ACCEPTED SOLUTION

Hello @jaskarangump,

Edge Microgateway uses JWT - which comes with an expiry, but cannot be revoked. JWT is used here primarily for federation, so Microgateway instances can authenticate and authorize without talking to any centralized auth server.

Can you describe your usecase?

Thanks,

View solution in original post

4 REPLIES 4

Hello @jaskarangump,

Edge Microgateway uses JWT - which comes with an expiry, but cannot be revoked. JWT is used here primarily for federation, so Microgateway instances can authenticate and authorize without talking to any centralized auth server.

Can you describe your usecase?

Thanks,

We're interested in any options to revoke access_tokens for Edge Microgateway deployments as well. Without the ability to revoke the access_token and just the refresh_token, we've had to wind down the expiry time for the JWT to 5 minutes. We'd really prefer to be able to support an hour, but that leaves the window for compromise too long for our security and compliance team.

Has there been any discussion about possibly providing a revocation list type solution, where edgemicro could ask Edge Cloud for the revocation list every 5 minutes. If any JWT tokens are received that match that revocation list then the request isn't honoured.

Former Community Member
Not applicable

@David Teirney, I fully agree with @Mukundha Madhavan the purpose of a JWT is federation and being stateless. It is difficult to implement revocation without maintaining some sort of state. Also, perhaps importantly, there is no IETF standard for this.

That said, I can think of a few strategies to deal with this:

1: Include another attribute in the JWT (at the time of issue). Some, like Auth0 has suggested to use JTI + SUB for this. At the time of validation, EM could callout another endpoint to get a list of blacklisted attributes (which it can cache). This can in fact, be another plugin. But you'd have to build some logic in Edge to maintain/persist this blacklist (KVM, BaaS etc.).

2: Consider using HMAC algorithms to sign the JWT. The secret to sign can be derived from developer key or secret (or both). Revoking application access can managed through Edge. EM will still have to reach out to Edge to get the application details.This revokes access on a per application basis whereas the previous technique revokes access on per user basis.

NOTE: EM is designed so it can function even if it loses connection to Edge. Quota enforcement may not be accurate and analytics is not published. In either of these strategies described above you'll have to see how to deal with this condition.

The ideal way to get this feature is through the use of opaque tokens (as Edge does).

Thanks for the reply. Our case for revocation is not application based (at this stage), it's user based. E.g. if a user looses their device for whatever reason we need a way to revoke any access tokens that have been issued for that user (to any application). We are generating our own JWT in Apigee that can be used for both Microgateway and also passed through to our application servers. The 5 minute expiry for the JWT is the compromise for the refresh_token being the only token that can be revoked.

We have implemented the RFC compliant revoke (https://tools.ietf.org/html/rfc7009) capability in Apigee Edge Cloud but we can't support the revocation of access_token's if we are using Edge Microgateway.

Thanks for the pointer to https://auth0.com/blog/blacklist-json-web-token-api-keys/. We are already using "aud" and "jti" claims so perhaps we have an option of storing revoked JWT tokens for the duration of our expiry window (1 hour) and we could expose an endpoint for an Edge Microgateway plugin to query that periodically.

Technically the five minute expiry shouldn't be a problem but it has caused a few challenges with applications where the user is very likely to be actively using the application (particularly web applications), and significantly hampers our ability to offer a sensible Implicit Grant OAuth 2.0 flow.