I am trying to connect React app and Rails app using Auth0. It used to be super simple since tokens were signed with HS256. But since auth.js v8 jwt tokens signed with RS256. I don't have problems with frontend but can't make RoR (I use Knock) work with new signing algorithm. I've added
config.token_signature_algorithm = 'RS256'
and
config.token_public_key = key.public_key
into Knock initializer but still no luck.
Key seems to be correct, at least it works in jwt.io or pure ruby-jwt (at least I was able to read information from token).
I am no expert working with asymmetric algorithms so any help would be appreciated. What I am trying to do right now is to get "access_token" from frontend and to send it in "authorization" header to the backend. I know I need to add "Bearer" into header but is there is any other operation I need to do with token first?
Best, Iurii
Just in case anyone interested here is short discussion on GitHub here is a link
Related
I am trying to do a request my Netsuite RESTlet using Alamofire (SWIFT) but I meet several difficulties:
In the documentation it's specify the different parameters needed (see below).
DOCUMENTATION:
An OAuth 1.0 RESTlet authorization header requires the data described in the following table. Some of these values can be obtained from the NetSuite UI. Other values must be calculated. Typically, your integration should include logic to identify these values and generate the finished header. Follow the OAuth 1.0 protocol to create the authorization header.
However in postman I am using extra parameters (consumer Secret and the Token Secret) and it's works if I remove them it doesn't works
To finish when i check the Authorization header generated by postman, I see only the specify parameters in the documentation :
OAuth realm="my realm",oauth_consumer_key="myConsumerKey",oauth_token="myAccessToken",
oauth_signature_method="HMAC-SHA1",oauth_timestamp="1543488570",
oauth_nonce="ERxdLbUfkeh",oauth_version="1.0",oauth_signature="UeqmxAyeUqtPoICLo%2FARsQE8B1E%3D"
If someone can explain me this, I could implement TBA authentification in my Application but for now I need to understand better this authentification.
I also spend a few hours trying to make it work. In my case I wasn't adding the account ID to the realm param. Here a picture of what I ended with:
Here where you can get the account ID:
I hope it helps
The explanation of why the consumer secret and the token secret are needed by Postman to generate the token is shown in SuiteAnswer 42019 - as referenced in the Notes section beside oauth_signature in your screenshot above. From that page:
Sign the result string from step 5 using the consumer secret and token secret concatenated using '&' (For this case, HMAC-SHA1 or HMAC-256).
In other words, Postman uses the secrets to generate the output which authenticates your credentials - you cannot generate the oauth_signature correctly without them.
I ran into a lot of issues with NetSuite broken RESTlet/TBA connections as well. I did build this out in our software to help out customers. You can see the methods I used in the article below.
Using NetSuite TBA by Calling a RESTlet from an HTTP Source or Target
I feel silly even asking this question, but am at the limits of my understanding, and am hoping someone can provide some context.
I'm looking at the following (https://stormpath.com/blog/token-auth-for-java/) which states:
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
I'm in the process of building a website, for which I'll be coding both the back-end REST service, as well as the front-end browser client. Given this context, why do I need to follow any of the guidelines given above? Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header? After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service? Are they analogous to coding-styles? Or is there any functional impact in not following the above guidelines?
Given this context, why do I need to follow any of the guidelines given above?
Because they are standardized specifications that everyone is meant to conform to if they want to interact with each other.
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
Nothing, except that it won't be OAuth anymore. It will be something custom that you created for yourself that noone else will understand how to use, unless you publish your own spec for it.
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Who is to say that you alone will ever write the only front-end? Or that the back-end will never move to another platform? Don't limit yourself to making something custom when there are open standards for this kind of stuff.
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
No. They are required protocol elements that help the client and server talk to each other in a standardized manner.
Authorization is a standard HTTP header used for authentication. It has a type so the client can specify what kind of authentication scheme it is using (Basic vs NTLM vs Bearer, etc). It is important for the client to specify the correct scheme being used, and for the server to handle only the schemes it recognizes.
Bearer is the type of authentication that OAuth uses in the Authorization header. access_token is a parameter of OAuth's Bearer authentication.
If you use the Authorization header (which you should), you must specify a type, as required by RFCs 2616 and 2617:
Authorization = "Authorization" ":" credentials
credentials = auth-scheme #auth-param
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
So, in this case, Bearer is the auth-scheme and access_token is an auth-param.
Are they analogous to coding-styles?
No.
Or is there any functional impact in not following the above guidelines?
Yes. A client using your custom authentication system will not be able to authenticate on any server that follows the established specifications. Your server will not be able to authenticate any client that does not use your custom authentication system.
I am trying to build a service that authenticates users using an oauth 1 signed request. The request includes an oauth token, signature, nonce, and consumer key. The server has access to the corresponding secrets, but it is unclear how to use the oauth gem to validate the token and retrieve the corresponding user. The token was originally generated using the oauth-rails plugin, but the validation needs to take place on a different server from the original rails application (but has access to the same underlying database).
How can I use the oauth gem to accomplish this?
I have looked through the source for the oauth and oauth-plugin gems, but I can't tell where this validation actually happens. Almost all of the documentation I can find refers to using the oauth gem as a consumer, not a provider.
I finally figured out the answer to this, so I'll put it here in the hopes of helping someone in the future.
Once you've retrieved the AccessToken and ClientApplication objects from the underlying database and checked the nonce and timestamp, verifying the signature is as easy as:
signature = OAuth::Signature.verify(request, {}) do |sigblock|
[token.secret, ca.secret]
end
If the signature checks out, signature will be true. Beware - if you're behind an http proxy such as nginx, the SERVER_PORT environment variable may not be correctly set for https requests and you may have to set it manually. If this (or any other seemingly tiny part of the request) is off, it can cause the signature verification to fail even if the request is valid.
This is probably a simple question but I can't seem to wrap my head around on how OAuth2 works. So I got upto the point where I can request a token and start pulling data in Ruby console. But after I exit out of Ruby console, I tried requesting data (.rb script) from API again using the same token but it says expired/invalid. Am I suppose to store this token somewhere permanently like in a database or cookie?
Not sure if this matters but when I request a token, it brings me to the OAuth2 page to allow or deny a token request. How do you bypass this in Ruby code? From what I'm reading, you use the token.refresh! method?
Can you please share your insights on what I'm not understanding or missing?
I generated my OAuth signature using twitter's own tool at https://dev.twitter.com/docs/api/1/post/statuses/update How do I use the "signature base string" and "authorization header" with CFHTTP to post a new status on my own twitter account. I'm not trying to access anyone else's account, just need to be able to post status updates to my own account. Your help is really appreciated.
Don't bother writing it yourself, use this: http://monkehtweet.riaforge.org/ its great I have used it many times for twitter integration.
If you want to write it yourself, you'll have to follow the instructions documented on https://dev.twitter.com/docs.
A signature is a serialization and encoding of all your request values in combination with a signing key. It's all very well documented at https://dev.twitter.com/docs/auth/creating-signature
You'll need the hmac-sha1 encoding to create a valid signature. If you're not using coldfusion 10, you'll need something like this: HMAC SHA1 ColdFusion