Two way SSL and OAuth2.0,massl oauth end point and massl proxy

Do we need massl enabled oauth end point for a massl enabled proxy? Or any other ouath endpoint within a org may work?

Solved Solved
0 1 846
1 ACCEPTED SOLUTION

Do we need massl enabled oauth end point for a massl enabled proxy?

No. Apigee won't make that a requirement. You *may* wish to use a 2-way TLS connection for token dispensing endpoint, but you are not required to do that.

Or any other oauth endpoint within a org may work?

Yes, you can dispense oauth tokens any way you wish. The OAuth specification stipulates that at least a 1-way TLS connection is used. And that's probably a good idea.

you didn't ask, but my opinion is that ... if you have an API that is available ONLY via 2-way TLS, then it shoiuld accept tokens that are dispensed ONLY via 2-way TLS.

And the way to do this is to have your token-dispensing proxy listen on 2 vhosts - one for 1-way TLS and one for 2-way TLS. And then at the time you generate the token, attach to the token, the name of the vhost used to request the token. And then at the time you verify / validate the token, verify that the token was dispensed with the 2-way TLS vhost.

You . could take it a step further by (at generation time) storing the fingerprint of the client TLS cert on the OAuth token, and then at Validation time, verifying that the fingerprint of the client TLS cert is the same as the fingerprint used to request the token initially. This is "token + TLS cert binding".

You could also do the same thing with TLS session ID. Bind the token to the TLS session.

View solution in original post

1 REPLY 1

Do we need massl enabled oauth end point for a massl enabled proxy?

No. Apigee won't make that a requirement. You *may* wish to use a 2-way TLS connection for token dispensing endpoint, but you are not required to do that.

Or any other oauth endpoint within a org may work?

Yes, you can dispense oauth tokens any way you wish. The OAuth specification stipulates that at least a 1-way TLS connection is used. And that's probably a good idea.

you didn't ask, but my opinion is that ... if you have an API that is available ONLY via 2-way TLS, then it shoiuld accept tokens that are dispensed ONLY via 2-way TLS.

And the way to do this is to have your token-dispensing proxy listen on 2 vhosts - one for 1-way TLS and one for 2-way TLS. And then at the time you generate the token, attach to the token, the name of the vhost used to request the token. And then at the time you verify / validate the token, verify that the token was dispensed with the 2-way TLS vhost.

You . could take it a step further by (at generation time) storing the fingerprint of the client TLS cert on the OAuth token, and then at Validation time, verifying that the fingerprint of the client TLS cert is the same as the fingerprint used to request the token initially. This is "token + TLS cert binding".

You could also do the same thing with TLS session ID. Bind the token to the TLS session.