I am using 2 Oauth services in my website. They both send back a query parameter called code. And I use a custom function to grab that code field when my page loads. Do OAuth services have a way you can change that code field to be custom? I am using Google OAuth for one and I am unable to locate this.
No, the standard specifies that the query parameter is named code, so there's no way to name them differently.
But the client can add a state parameter to the authorization request, which the authorization server has to return with the code. You can use that parameter to distinguish between the two authorization requests.
Related
I would like to customize how the TokenEndpoint works so that I can add additional parameters to to incoming /oauth/token rest call that I will capture and process.
Ok, to perhaps help explain what I want to do, here are some additional aspects to it.
Lets say, in the oauth/token request I want to add another request parameter entry. So instead of sending the oauth/token with grant_type=client_credentials (for example), I want to add grant_type=client_credentials&extraInfo=xxxx.
So my my token endpoint that I have running at request mapping /oauth/token instead of the builtin one (TokenEndpoint), I do everything that the original does PLUS, I parse the extraInfo=xxx and set it as a key/value in the additional info section of the token.
Later in my backend, I extract this extra info and use it to provide some functionality that I need. Various clients will use this extraInfo parameter to send some specific type of information that I was to be aware of.
So basically, ow do I substitute my own token endpoint in place of the regular one? Is this in token services and if so which specific part?
I figured out an alternative to what i want to do without any of the messiness of trying to create and hook in my custom Token Endpoint.
I put an aspect around (#Around ...) the TokenEndpoint and captured the incoming parameters and resultant token, etc. I then used the spring session framework to put in a structure that I can access (created from what came in) and now I can get at it in my resultant code.
This does what I want without needing to do something more complex.
I want to write a Jax-Rs handler which should get all the REST calls given from a REST client and validate the OAuth access token and forward the http request to the respective resource classes.
I meant to say that, Jax-Rs handler will be the central place to handle all the request by validating the value passed by Authorization header.
I am expecting an urgent reply.
Take a look at how it's done in rexsl-page. Take a look at two classes, one for Google OAuth and another one for Facebook OAuth. You can also use the entire framework, or just copy given classes.
In a nutshell, you create a common parent class for all your JAX-RS resources. In this class you parse incoming HttpHeaders and tries to find a cookie with an encrypted authentication token (user identity). If found, you do nothing. If not found, you throw a WebApplicationException that redirects the user to the "please login" page.
A common use case for WebAPI would be to have shell views rendered by MVC controllers, which contain javascript that then hit your API to access data.
But let's say you have some expensive API operations and you don't want people remotely accessing those endpoints -- you only want your MVC views, delivered by your application, to access them. How could you go about protecting them?
In this case Request.IsLocal doesn't work, because javascript is invoking it from the client's browser on their machine. Even if it did work, you need to dig to get the real HttpContext in order to find this property -- and that solution wouldn't work in self-hosted WebAPI.
For API endpoints that require a valid IPrincipal, you could protect them with the [Authorize] attribute. But what about API endpoints that you want your app to be able to access for anonymous users?
I have tried a solution and will post it separately as an answer, because I'm not sure if it's the best (or even a good) approach.
If your MVC site uses authentication, you could enable forms authentication for your Web API methods. You could write a custom [Authorize] attribute that will check for the presence of a forms authentication cookie which will be sent from the AJAX call and if present construct the principal.
Another possible solution is to protect your API with tokens which is a more RESTful style. The idea here is that when a user authenticates on your MVC website you could generate and pass a token to the view which will be used when sending the AJAX request to the Web API which in turn will verify the validity of the token and its signature.
If on the other hand your site doesn't use authentication, then things will get very complicated because you have no way of knowing whether the request comes from a trusted client since you are using javascript to call your API methods.
Before you go harping about "what have you tried", here is what I have tried. It works. Just not sure if there is a better way.
Create an MVC action filter and add it as a global filter during Application_Start.
Create an Http (WebAPI) action filter and use it on actions that should reject remote requests.
The global MVC filter does this:
Looks for a specific cookie in the request. If the cookie is there, its value is decrypted. The decrypted value should be a string representation of a DateTime, so use DateTime.TryParse to get it out. If the value is correctly parsed to a DateTime, and that DateTime is less than a day old, STOP HERE and do nothing else.
If the cookie is not there, or cannot be decrypted / parsed, or is older than a day, write a new cookie to the browser. Use the current DateTime.UtcNow.ToString() as the value, encrypt it, and write it with HttpOnly = false.
The WebAPI filter does this:
Looks for a specific cookie in the request. If the cookie is there, decrypt its value and try to parse it out as a DateTime.
If the value is a valid DateTime and is less than 2 days old, STOP HERE and do nothing else.
Otherwise, throw a 403 Forbidden exception.
A couple of notes about my current implementation of this. First of all, I use AES encryption with a shared secret and a salt. The shared secret is stored as an appSetting in web.config. For the salt, I enabled anonymous identification and used Request.AnonymousID as the salt. I'm not entirely fond of the salt because it's tricker to get at in a WebAPI controller, but not impossible as long as it is not self-hosted.
I'm Using OAuth2 with Doorkeeper to protect my API.
The problem is that one client had several different flows in which he redirects users to my OAuth flow.
He would like to dynamically add some parameters when redirecting the user to my OAuth flow and get these parameters back when I'm calling his callback URL. This way he will be able to tell from which flow this callback originated.
Is this possible with OAuth 2? with Doorkeeper? How?
Edit:
Thanks Zólyomi István for your hint.
I set the state parameter before calling the auth endpoint and got it back in the callback. However, I found that I get back a state parameter with some apparently random string even if I don't set anything. Any idea what it is? I'd like to be sure I'm not messing up anything...
Well, using the state parameter was indeed the solution. Just adding state to the request and then getting it back when the control is returned to my code.
According to the specification:
The state parameter is used to link requests and callbacks to prevent
CSRF attacks where an attacker authorizes access to his own resources
and then tricks a users into following a edirect with the attacker's
token.
Apparently ominauth oauth 2 assigns random value to this parameter unless it's used in order to detect CSRF attacks.
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.