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.
Related
I have a default Spring authorization Server implementation. i want to modify it as per my project requirements.
I want to implement customized introspection endpoint in new spring authorization server.
I will be having different kinds of tokens, based on token type I want to validate them differently.
So I found out by default spring authorization server uses 'OAuth2TokenIntrospectionEndpointFilter', is there a way to use this class or we have to write a new class and add it to server configuration?
Thank you.
I tried doing the following.
authorizationServerConfigurer.tokenIntrospectionEndpoint(
t -> t.authenticationProvider(customTokenAuthProvider)
.introspectionResponseHandler(successHandler));
I want to know if this the right way to do or any other method exists.
It seems you have two goals:
Customize a jwt, by adding custom claims.
Obtain those claims via the introspection endpoint from a resource server.
There is actually nothing to code for on the authorization server side to achieve #2, as the introspection endpoint returns all claims for a jwt by default. I’m not clear on what you mean by “validate” here, so I’m assuming you mean validate the token and then obtain claims from it. This is what the introspection endpoint does, no customization required. Do note however that the introspection endpoint is not usually called if the resource server is decoding the jwt locally. This would only happen if the resource server is treating the token as opaque.
In order to achieve #1, simply provide an OAuth2TokenCustomizer #Bean as demonstrated in the reference documentation.
Note: I don’t see a need for a custom AuthenticationProvider. If you feel you do have a need for one, then I think some details of your use case are missing.
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.
I need to add a token inside a token for an "act-as" schema on a custom grant type in IdentityServer3.
I tried with PreserveAccessToken but it just adds the token as a claim in the current ClaimsPrincipal, but can't find a way to nesting it as a claim when getting another token to pass along to the next service/api in the chain.
The idea behind this is for being able to keep an audit of all the hops from the end-user to the last service/api in a chain of calls.
This can be achieved using a custom grant. This allows extending the token endpoint with custom "operations" - e.g. issuing a token that contains delegated claims - e.g. a token.
docs are here: https://identityserver.github.io/Documentation/docsv2/advanced/customGrantTypes.html
here is also a sample that comes close to your scenario: https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Multi%20Hop%20Delegation%20(ActAsCustomGrant)
that said - this is probably the most expensive way to convey a user id over multiple hops.
If there is a trusted subsystem between the back-end system, simply transmitting the required data as payload is much simpler and much faster.
This tutorial for building API's with Devise recommends using headers to send over the login email and API token vs. embeding them as URL parameters.
Rather than sending the data over parameters, we're expecting the client application to send it via two headers: "X-API-EMAIL" and "X-API-TOKEN"; this cleans up the endpoint URIs.
Can someone elaborate on what it means to "clean up" theWhat are the the advantages of requiring authentication via headers vs. having the client embed them as parameters in the URL?
I think by "clean up" they just mean that the URLs are tidier and only contain information about the resource being requested/updated/...
It's common to use this approach -- it can be argued that it's conceptually nicer to keep what you are requesting somewhat separate from the details of your credentials for making the request. The "Authorization" HTTP header is a standard one to use for credentials (e.g. HTTP Basic Auth http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side, AWS API http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader and many more).
It also removes the possibility of clashes between your credential parameters and other parameters. For a trivial example, imagine you use password for your credential password and also want a normal parameter called password for a particular API call (when you're updating another user perhaps). You can't have that - one of them has to be named differently. Ok, you can easily do that, but it's a little artificial, and if you instead supply the password for the credentials in the Authorization header, you are free to have a parameter called password which relates to the actual request you are making (e.g. the new password you're setting for some other user).
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.