I need to validate the id_token I receive after authenticating with Auth0 on my website.
I know that I need to use the key in x5c from the jwks_uri.
But what I don't know is if this information is stored somewhere by the OIDC-client-js component after being authenticated.
If so where can I find it to use it ?
Or do I have to manually make a request to https://myapplication/.well-known/jwks.json ?
Thanks in advance for your help.
The oidc-client-js seems to be already validating an ID Token when it receives one, but if you want to do it manually anyway, you should have access to the metadataService on the UserManager object, and the metadataService has a getSigningKeys() method, which will either return keys from the cache or download them from the jwks endpoint. Just remember that there is much more to be done to verify the ID token, so it's really worth rethinking if you should do it on your own if you're already using a library which does that.
You can have a look how much work is done to validate the ID token in the oidc-client-js: https://github.com/IdentityModel/oidc-client-js/blob/c150cd26dd29a09fedb4faaa95f00c16ddd90906/src/ResponseValidator.js#L354
Related
I am working with the eBay API using OAuth on my current Meteor project app.
There is a section of the app where I can create an eBay account profile, and assign custom values to the account (such as nick-naming it, etc.). This is where I initiate the OAuth sign-in redirect process.
My question is about the 'state' parameter in the token requests. I understand that it is for helping prevent CSRF, but do I HAVE to use it that way? 'state' does seem to be optional after all.
Let's say I wanted to pass another value into the request call such as the string 'eBay Seller', and expect that the same exact string be returned in the response. I want to use that value to help my app determine which account to assign the returned tokens to (based on which account profile initiated the redirect link).
Is 'state' a valid place to pass in a variable that I expect to be returned exactly as sent? I considered using Session variables to handle this scenario, but quickly realized that this would not work, since the OAuth process takes me outside of my project's domain.
Does OAuth support passing variables that are expected to be returned as sent? Is sending my variable as 'state' allowed or even recommended (or absolutely not recommended?) Is there a better way to achieve what I want to do that does not involve updating database values?
Thank you!
You can send what you want as state. You should try to make sure it's not guessable though, to mitigate against CSRF attacks.
If you want to return useful information like 'ebay seller' then include something for CSRF (e.g. hash of the session key id) and the text 'ebay seller' and delimit them e.g.
2CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B9824|ebay seller
Now you have the best of both worlds: useful state info + CSRF protection.
Your redirect endpoint logic can check the hash of the session id matches and also confirm the account type from the initial request.
I have created an authentication server that implements OAuth 2 for authorization and it also provides local password authentication using the resource owner flow.
At the moment I always return a refresh token along with the access token which was an acceptable thing to do when I first implemented the feature. However now I need to implement a remember me feature in the client that uses the server. I could always just save the refresh token in the client when the user ticks the remember me checkbox but the token would still exist on the server and be usable even though the user didn't want it to.
What I want to do is simply pass a parameter along with the request that tells me whether I should create a refresh token or not.
So my question is. Is there some standard or recommended way of doing this using the fields provided in the spec or is it acceptable to simply add a parameter to the request to handle this use case?
AFAIK, there is no standardized way to choose whether to issue a refresh token or not.
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.
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.
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.