I am new to OAuth.
Is a signature the same thing as a secret?
I looked at this, but still was not sure.
A signature is created with a secret, and with other data from your request.
After this signature is created by the client, the server will use the same information to see if the signature was correct.
This allows the server to be sure that the client has a copy of the secret, without requiring the client to actually send the secret.
Related
Ok, user authenticates and client gets the JWT from my IS4 instance. All that works. Now, for reasons I still cry at nights after being tormented by people who authoritatively claim to know OAuth but do not, the client is sending me the identity token JWT over the wire to an action, and I need to do some work based on the subject in it. I want to minimize the fallout of this decision and prevent a situation where someone plants me a fake token, so I want to validate the JWT to make sure it came from me, that indeed I am the one who issued it. To simplify, I need to act as both the client and the server in the token validation process, while running on the IS4.
Since this is such a violation of OAuth protocol, I am not sure this is supported out of the box, but here comes: is there a way to do this? I even tried to introspect the token, but that requires an authentication context, and I can't seem to get the client credential flow working since I only use openid/profile scopes and they are not supported by the client credential flow (since the user is defined only in JWT).
The receiver of a token should always validate the signature of the token to make sure it came from your IdentityServer. This is usually automatically done by most proper JWT-libraries. The library will download the public-key from your IdentityServer and use it to verify the signature of the token.
If you are using ASP.NET, then the JwtBearer library will do that for you.
I have a service protected with OAuth. For it to use, you first require a token.
I have an app, that has only access to an Apigee proxy. I would like Apigee to do the authentication for the client (app), and setup protection with an API key for the client in Apigee. How do I do that?
I think what you are trying to do is what Apigee refers to as Last Mile Security. Unfortunately, it's not as simple as adding a policy and configuring it with a token URL, client ID, and secret. You'll want to make sure you securely store the credentials, cache the token appropriately, and pass the token on to the proxy target.
Fortunately for you, Apigee has a demo project that does what I believe you are trying to do. Basically, your proxy will be configured with simply the Verify API Key Policy (Do this first as if the api key isn't correct, no need to do all the OAuth handshaking). Once confirmed, you can use Javascript policies to check the cache for a token, and then call the OAuth token endpoint to get one if there is a cache miss. I believe it then uses the AssignMessage policy to set the Authorization header to the token. (Note that the example project does not include the Verify API Key policy, but that should be easy enough to add)
Additionally, the demo project stores the client ID and secret in a js file, which I would not recommend. Maybe store it in an encrypted KVM entries?
The Outbound OAuth sample project can be found here.
please refer to below videos for using oauth authentication in your API proxies:
https://www.youtube.com/watch?v=zn94GhcdgHc&list=PLsWqc60hQz4clQ4ykjCu4qyEhdKe11Lvy
You can use Ouath2 - client credential grant Type, that implies that you must add and configure security policies in your proxy, check the following link that explains this flow.
https://docs.apigee.com/api-platform/security/oauth/oauth-20-client-credentials-grant-type
I have been trying to understand how OAuth2 works. At first I thought it was redundant to spend one extra step exchanging auth code + client secret for access token - why not have server return access token directly. For that I found this explanation.
Then what confuses me is, why does it need a clientId and a client secret, instead of just a secret? A secret which can both declare and prove itself. The client app then can simply pass it to server when it sends user there to authorize itself for accessing server resource.
Thanks!
Imagine the client signs the request with the secret and sends just the signature. How does the server know which secret to use? Presumably the server supports multiple consumers.
The client id is sent in the first part of the token dance to identify the client. This id is sent in an insecure way, in the URL. Even on the authz server end of this request the id may be exposed in an insecure way where the authz server redirects the user agent to the authorization page. So the client id is not meant to be secure, just to identify the client.
Only after receiving the authorization code (after user authorization), does the client then need to obtain the access token in a more secured way. This is where the client secret is used over TLS.
You can have the server return the access token directly. You need to request Implicit grant (response_type with the value token instead of code).
The authorization server returns the access token directly.
This type of grant is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret or client id because all of the application code and storage is easily accessible. If your client can keep a secret, it is recommended that you use a more secure grant type.
I'm implementing an OAuth secured API, and I assign each client a consumer key and secret. I don't want to assign a separate API key for clients and me to have to keep track of. I'm thinking that authentication happens like this: they generate their payload and sign it with their key and secret, and transmit the key.
On the server, I store the client secret, keyed by their key. When I receive the payload, I use their key to look up the secret, then I decode the payload with that secret. So the secret is not transmitted, but the key is.
So my question is: is this a safe way to handle this situation, or am I missing something important here?
If you are talking about how a client authenticates to the authorization server, OAuth 2.0 requires that the endpoint is secured with TLS, so recommends just using Basic authentication.
My understanding of the 'key' (or 'token') in OAUTH system is like a 'username' to identify the sender which is not confidential but 'secret' is actually like a 'password'.
But reading through the OAUTH 1.0 spec on http://oauth.net/core/1.0/#signing_process, it seems to me when consumer asks service provider for a token (either request token or access token) , the token and token secret are returned in PLAIN (just base-64 encoded) text as HTTP response.
And after searching web it looks in lots of not all case, the "request token URL" is HTTP not HTTPS which means a 3rd party may intercept the token and token secret.
So am I wrong thus far? I know even a 3rd party intercepted the token secret it's still useless as any request by consumer (or any party claim as the consumer) must be signatured with consumer key (plus token secrect) which the 3rd party usually don't know, but then why we need the token secret then?
Although it is permitted to use http, it is recommended (see appendix B.1) to use secure transport (https), otherwise your concerns are quite valid. I know for sure Google allows https:// on all their OAuth transactions, at least as far as getting the token and secret, and for all the API data requests that I've tried so far.