How to encrypt and decrypt access token in apigeex?

[madhavikris]

I have a requirement where access token generated using password grant type should encrypted from front end and decrypted at apigee x. Please suggest how to accomplish this @Dino Chiesa pleae suggest.

[dchiesa1 · Accepted solution]

Before I can provide a practical answer, I'll need you to explain your requirements a little further. 

But first, some context I would like to share: An Access token is "a secret" which you do want to keep private.  But, typically OAuth tokens are "bearer tokens" , and per IETF RFC 6750, bearer tokens  are deliberately intended to be usable by any party in possession of the token.  

They specifically did not want apps or developers to have to deal with encryption or secure long term storage of the access token. For that reason the OAuth specifications made recommendations to limit the validity/expiry of bearer tokens, so that the loss or leakage of a token would result in only a limited window of vulnerability, like say, 15 minutes, after which the token expires naturally. It is unlike leakage of a password, in that respect. Basically, tokens are ephemeral.  Passwords change must less often; they are persistent.  In fact some of my passwords I haven't changed in YEARS.  That's why authentication systems must not store passwords - any leakage of a password is a serious problem.  Access tokens are different, based on their brief lifetime.

When apps follow the OAuth spec and recommendations, they encrypt tokens in transit, because the token is passed in an HTTP header, and because OAuth requires that you always use TLS  when dispensing tokens and when using tokens.  If you follow that, then there's a transport layer that auto-magically encrypts the token, so that only the receiving endpoint can decrypt it. 

ok, given all that, what are your requirements, in more detail?  What do you intend to accomplish by encrypting, at the application layer, a bearer token obtained through the password grant?  What is the real goal here?  What threat are you protecting against?  Maybe elaborate in two or three paragraphs of explanation .

Encryption is a handy digital technique for obscuring data, but really it just replaces one kind of problem (making arbitrary data "private") with another kind of problem (key management).  It is not possible to avoid the key management problem when you're talking about two parties or systems, like an App connecting to Apigee, using application-layer encryption to keep data private.   So what is your thinking around key management?  Do you think you will use  symmetric encryption via secret keys?    or or asymmetric encryption algorithms using public/private key pairs?   And what's your thinking around key generation and storage, how would that work?  

[madhavikris]

As per security team, Basic auth may be tampered while transmitting data visible. Is there any way to encrypt basic auth front end side and decrypt it in apigee for oauth2 password grant type.

[dchiesa1]

Is there any way to encrypt basic auth front end side and decrypt it in apigee for oauth2 password grant type.

ok, so I understand you do not wish to encrypt a bearer token, but you wish to encrypt the credentials used in the request-for-token, specifically the client credentials.

In that case my answer is not automatically, but YES you can do it, but also you probably don't want to do it. (bear with me)

For the password grant as specified in IETF RFC 6749, the client transmits its credentials via basic auth . That means the client passes its ID and secret, base64 encoded. The client always transmits a secret.

You could build your own "protocol" or grant type, to supplant or replace that approach. OAuthV2 is intended to be a framework that is extensible, so it's "within the spirit of OAuth" to define a new/distinct way to request tokens. To do this, you'd need to define how the client should encrypt it's credentials, (and using what key), and then have the Apigee side (the token dispensing side) decrypt. Key management would be a significant part of the design of this new grant type. so YES, you can encrypt, but there is a significant burden to doing it.

You said your goal is :encrypting basic auth:. But in fact that is a proposed solution to the problem of preventing the threat of tampering or viewing the basic auth creds. I think the main goal is to maintain privacy of the credentials. In practice the best way to do that is to NOT transmit the credentials at all.

If that sounds right to you, a better way to maybe accomplish your goal would be to use a grant-type that does not REQUIRE transmitting secrets. The grant type urn:ietf:params:oauth:client-assertion-type:jwt-bearer (short form: "JWT Bearer"), specified in IETF RFC 7523, may give you that. It describes a way for a client to SIGN (not encrypt) a payload and transmit that signed payload in a request-for-token. The signed payload need not include a secret. So basically, you don't want to encrypt basic auth. You can supplant that with the use of a signed payload.

The signing can use any key - one option is to use RSA keys and RSA signing - like a JWT signed with RS256 algorithm. But you could also use secret keys, and HMACs (eg, JWT with HS256 algorithm). And your client already possesses the secret key - the client secret. In Apigee X, that secret carries suitable entropy to be used a cryptographic key for HMAC-sha256. If a client signs with its secret key, it's easy for Apigee to "look up" the secret key upon receipt of such a JWT, and then verify the signature.

I recorded a screencast a while ago on this topic. If I recall correctly, I think I used ONLY RSA-based signing. But you don't need to use RSA signing for this grant type. You can use HS256. The approach is the same: receive the JWT, decode it to get the client ID, lookup the signing key, verify the signature.

Keep in mind this JWT is intended to authenticate THE CLIENT, not the user. If you are replacing a password grant, then you would want the signed JWT to also include the username to be authenticated, along with the password. This JWT would be sent in a payload and would be encrypted via HTTPS (TLS).

If you're not happy with sending passwords over HTTPS, then you should replace password grant with authorization_code grant - still you can use the JWT bearer for identifying/authenticating the client, as shown in Sec 2.2 of RFC 7523.

I hope all this makes sense! Good luck.

[madhavikris]

How to bind user with password token.Please suggest @dchiesa1 ...