I am looking at OAuth1.0A documentation to implement similar protocol. Doing this, I'm trying to find justification for every element in the request.
I wonder what's signature for. So far I understand that signature can be used to guarantee of data integrity. But, what if a hacker crafts the signature using oauth_signature_method stated in oauth request?
I have known that we can guarantee the sender identity by appending shared secret to base string before encoding. Then, the signature is worth only when shared secret is appended. Right?
Related
I'm trying to validate a google jwt I got from the client, but most of the information I can find online is lacking.
For instance, this post on Stack Overflow:
From
https://developers.google.com/accounts/docs/OAuth2Login#validatinganidtoken
the recommended approach:
"we recommend that you retrieve Google’s public keys from
https://www.googleapis.com/oauth2/v1/certs and perform the validation
locally.
Since Google changes its public keys only infrequently (on the order
of once per day), you can cache them and, in the vast majority of
cases, perform local validation much more efficiently than by using
the TokenInfo endpoint. This requires retrieving and parsing
certificates, and making the appropriate crypto calls to check the
signature. Fortunately, there are well-debugged libraries available in
a wide variety of languages to accomplish this."
It isn't clear to me what I'm supposed to do to validate this jwt. Most of the information I can find about how to verify the signature says to use the x5c key from jwks, but Google's page, found through the discovery doc, excludes that key.
Validation of JWT is covered in the spec (RFC 7519, section 7.2). One of the steps is validation of a signature, it's covered in JSON Web Signature (JWS) spec (RFC 7515, section 5.2). Specifications are the law but to apply the law you should understand how most applications do it or should do it. That is covered in JWT - Best Current Practices (JWT BCP; draft 06)
You can read all of that and try to implement it on your own or you can use one of the client libraries Google provides for you where all of this is, well, also done for you.
I am going through http://aiten.github.com/grails-oauth-scribe/guide/usingThePlugin.html
My main problem is, I have my linkedin access token, but this API forces me to use
Token linkedInAccessToken = oauthService.findSessionKeyForAccessToken('linkedin')
I want to init Token object with a string.
I could not find the API documentation anywhere, please help
Edvinas has it - the Token object (from Scribe) allows init as he specifies.
There is also an optional third parameter, which is the entire raw oauth response from the server, useful if you want to grab/store expiration info etc.
Also as Jeff says, the plugin is designed such that you can happily use the token throughout without worrying about it - it's much cleaner to store objects as object rather than a String, and might help avoid strange runtime errors in your code.
If you want to store it as a Map you should serialize it as such first.
Source:
I wrote the plugin.
If you already have the access token you wouldn't need to really do the oauth request you could just make the request with token you have. Below change linkedInAccessToken to the string that has the token.
oauthService.postLinkedInResource(linkedInAccessToken, 'http://api.yourprovider.com/users/list')
I guess you want to persist the token object. It consists two Sting fiekds: token and secret. When you have them stored in the database you can always create the token simply:
Token linedInAcessToken = new org.scribe.model.Token(token, secret)
This can be later used in oauthService.
When an OAuth signed request is made to a Rails 3 app, I can see the OAuth consumer key in amongst the other values in request.headers["HTTP_AUTHORIZATION"]. What is a better way to access it? I'm using the OAuth gem.
According to this section in the OAuth specification, the Authorization header is the preferred way of sending OAuth protocol parameters. The specification does make allowances for sending protocol parameters in a form encoded body or in the request URI, if the request meets certain requirements.
To answer your question: parsing the Authorization header is a must for any OAuth provider. But you may also look for it (and other protocol parameters) amongst "normal" parameters, you will never find them in more than one place,
I'm designing a Service Oriented Architecture, and I also do need an authentication service in order to recognize clients and allow them to access resources.
Actually I found two possible solutions:
sign each single request using a pubkey and privatekey
token-based authentication using pubkey and privatekey
I'm not assuming an oauth2 service since it would add too many overhead designing the system for my needs, instead I do prefer to adopt a simpler (but also strong) authentication solution.
So here I come with my AuthenticationService, that can either be queried by the client making the API request (obtaining a token to pass alongside the request) or be queried by each single API endpoint to perform a reverse check of the HMAC that signed the request to see if it matches (checking if the private key used to produce the HMAC was valid).
I can see the latest to be simpler for the final developer performing several operations, but it would also require more checks to validate the token and handle it's expiration...
What potential security issues could the token solution raise that the single-request HMAC doesn't? What do you prefer and, possibly, why?
At the end I finally designed an authentication service based on the same Amazon solution.
It requires users to sign each request using the private key. So the request will send an Authorization header with the value "PUBKEY:SIGNATURE", where the signature is a HMAC composed of any request data (it could be the request body itself) plus a timestamp, to be passed inside the Date header. This implementation is strong enough to avoid MITM and replay attacks.
For more info about this solution here is a great explanation that helped me a lot to understand the real implementation.
Hope this really help someone else in the world facing the same problem.
I am writing a web application using server-side authentication, and I've been trying to figure out a way to leverage Facebook's Javascript SDK in my application.
The documentation for FB.init defines the optional authResponse parameter as something used to "Manually set the object retrievable from getAuthResponse". It also states that once obtained, an application may store the entire authResponse object for future access. This may work if an application uses FB.login, the Javascript SDK's authentication, but what about an app using server-side authentication?
Server-side authentication enables my app to obtain a user's access token, the most crucial piece of information needed for graph API calls. I would hope that this access_token alone would be enough to construct a valid authResponse object to use to authenticate to use with the Javascript SDK.
Merely calling FB.init (with valid appID, channelUrl, and other parameters) with an authResponse containing a valid "accessToken" field is not sufficient. Including the userId is also insufficient. Ideally, these parameters alone would work. The only others defined for the authResponse are 'expiresIn' and 'signedRequest'. Which, if either, of these parameters would be sufficient to generate a valid authResponse object? To what values must they be assigned?
I managed to dig up this description of a 'signedRequest':
https://developers.facebook.com/docs/authentication/signed_request/
This document raises a number of questions. I assume that the signature is produced by a symmetric algorithm. If not, then generating it would not be possible. Assuming it is possible, the description of the payload is in no way specific. There is a list of 9 parameters, none of which are labeled as required.
Like CBroe says, you shouldn't be passing anything manually. You start with a call to FB.getLoginStatus and pass your javascript handler as an argument to this method. You will have the authResponse returned back from the getLoginStatus call.
You can, of course, in theory pass the access_token param around to any FB.api call e.g. /me?access_token=blah_blah, where blah_blah is the string you have but again, this is not required and you are better off delegating this to the response handlers.
Be very careful when using the javascript sdk and server side authentication for access token generation/extension/verification. You end up maintaining two separate code paths and end up making the same call to Facebook over and over again. Even if you are storing the access token on your side, would be always better to pick one approach that works best for you, rather than having a server side call to get access token and a client side call to FB.api to use the access token.
There is a solution for that. I didn't think that it's so easy.
FB.api('/me?access_token={{ access_token }}', function (me) {
console.log(me); //do anything with me
});
So you didn't need to set an Objekt Variable in FB before -
simply add the access_token as parameter with your request.