I'm developing backend for oauth2 client. I'm using authorization_grant flow with PKCE extension. I'm trying to implement it in such way that code verifier and code challenge is generated on clients side. So i have to add additional parameters to my token request (the second request, when input is authorization code and my application exchange it for access token).
My app will have to take this code_verifier from request param and pass it to authorization server with authorization code, client id, and client secret.
So now I'm struggling with customizing spring-security-oauth2-client to add additional parameter. There is way to add such parameters to authorization request by implementing OAuth2AuthorizationRequestResolver, but is there analogical way for adding parameters to token request?
Or maybe should i implement this endpoint manually?
I feel your pain, since Spring OAuth Security is often poorly documented for common use cases. One option you might consider is to provide a custom Spring filter that uses the open source nimbusds libraries, which have very good documentation and are easy to use.
Related
I am implementing REST services using springMVC. Now i have added basic authentication entry point in my spring security file. But i don`t know that, Once user authenticated by passing credentials in Authorization header does he need to pass those credentials for all subsequent requests?
for example,
I have two URLs:
1) localhost/apppName/login
// Here user passes credentials in Authorization header. So, user authenticated successfully.
2) localhost/appName/getUsers/1
//Here, client need to pass those credentials in Authorization header?
if it is needed, then why spring kept prinicpal object in the SecurityContextHoder after authentication done via BasicAuthenitcationEntryPoint?
Clients of this services can be any thing like Android, java, .Net
Any suggestions will be appreciated.
Pure REST is stateless, which means that no client context is being stored on the server between requests. That means you need to send the Authorization header for each request.
You don't need to hit the login URL when using Basic auth, that's the point.
However, you can use sessions in combination with Basic auth, and in that case you should pass session cookie between requests. It may have some performance advantage, but generally I would not recommend it.
In previous versions of ASP.NET you got authorization and authentication out of the box from the default template.
I have a Web API application and three or four well defined clients that will consume it and I need to secure it.
I read about OpenID and OAuth but they seem like an overkill for my problem.
What's the simplest way to achieve that?
These would be the 3 best solutions if you require security:
WEB API browser client: Implicit OAuth 2 flow
WEB API Application client: OAuth2 code flow
(With OpenId)
OR: Cookie Authentication with Cross-site request forgery protection. (Default template MVC 6 website template)
If your application is public, I would use at least one of these, otherwise it depends on how secure your data must be.
Well, it depends on your scenario. If you don't need authentication (because it's a server-to-server scenario), use a security token as described below. If you need authentication of the user, you may use Basic or Digest security combined with HTTPS.
In a security token scenario, the client simply has to add the token to the request headers and the server needs to validate the token. Make sure the requests transit as HTTPS to make sure the token is encrypted. Remember, this method is only valid if you know the applications that will access your API will be in a secure environment (another server, for example). Otherwise, I would go for another solution.
I currently have a distributed system containing an OpenID Connect server (IdentityServer3) acting as SSO server. The clients using the SSO server are AngularJS SPA:s with WebAPI v2 backends.
I got the basic login flow working, but I need some help with configuring the WebAPI/OWIN pipeline to allow transformation of the received token claims, ie. removing unnessecary claims and adding local claims. I'm assuming I need to create a local JWT instead of using the JWT received from the SSO server.
The question is, what is the best way of doing this? Are there OWIN middlewares that can help with this, or do I need to "manually" generate a new locally signed JWT from the claims received from the SSO server?
Current implementation details:
The AngularJS SPA authenticates against the SSO server using
authorization code flow and receives the authorization code.
The SPA posts the authorization code to the WebAPI.
WebAPI receives the authorization code and requests an AccessToken/JWT from the SSO server using the OAuth2Client class (part of Thinktecture.IdentityModel.Clients). This AccessToken is returned to the SPA to use in any further requests done to the WebAPI.
So my question mostly relates to step 3. How do I best change my current flow to generate a token also containing the local claims?
Also, what kind of authentication middleware should be used with your proposed solution (JwtBearerAuthentication, OpenIdConnectAuthentication or OAuthBearerAuthentication)?
Apoligizes for my probably confused terminology usage, I'm a beginner regarding OAuth and especially the OWIN pipeline. :)
Your WebApi should use BearerTokenAuthentication.
To get access token (access_token) and claims (id_token) in single call you need to set response type as ResponseType="token id_token"
You can checkout various ready to run sample at IdentityServer3 Samples. Specifically checkout implicit flow sample.
I am currently developing an API that I plan to secure using oauth2.
I have chosen: https://github.com/lucadegasperi/oauth2-server-laravel/
I have managed to secure the endpoint (using before=>oauth in my api routes) by following the installation guide but I am at a loss as to how am I gonna be able to authenticate and access the endpoint.
I do understand that you will first need to request an access_token by sending a client_id and client_secret but what I don't get is where do I set those on the oauth server?
I see the oauth controller has endpoints for these like:
http://somedomain.com/oauth/authorize
http://somedomain.com/oauth/access_token
But I am clueless with what to do with them. I only managed to arrive at the conclusion that it needs a client_id, client_secret, and stuff about scopes.
Where can I set these values for the api client to use?
Thank you for your help in advance.
I don't know Laravel, but in general, the authorization endpoint (in your case, http://somedomain.com/oauth/authorize) behaves as described in RFC 6749.
The specification defines four flows. If you use Authorization Code Flow among the flows, you should access the authorization endpoint with the following request parameters.
response_type=code (required)
client_id={your-client-id} (required)
scope={space-delimited-scope-names} (optional)
redirect_uri={your-redirect-uri} (conditionally optional)
state={any-arbitrary-string} (optional)
For example,
http://somedomain.com/oauth/authorize?response_type=code&client_id=your-client-id&scope=profile+email
The authorization endpoint generates an authorization code and returns it to your browser.
The next step is to access the token endpoint (in your case, http://somedomain.com/oauth/access_token) with the authorization code which has been issued from the authorization endpoint. Like this,
POST
http://somedomain.com/oauth/access_token?grant_type=authorization_code&code=issued-authorization-code&client_id=your-client-id&client_secret=your-client-secret
Anyway, I recommend you read RFC 6749.
Ok, the situation is this.
We already have an existing ASP.NET MVC 5 site with Custom Forms Authentication, Logon, Registration etc with a custom database for roles and profiles already implemented.
We now are adding some new functionality to the MVC site and we decided to use Web Api 2 OData 3 endpoint which lives in another domain. The Web Api currently doesn't include any authentication but we need to be able to map the requests to a certain user to get his roles etc from the backend. The MVC and API sites use the same backend.
What we would like to accomplish is, that when the user logs on in the MVC site, the MVC site calls the Web Api server-to-server with the user's credentials and receives a token that the client can then use to call the web service with.
When API receives a request with the token, it can then map the request with the user in backend and do authorization.
As far as I understand it, Simple Web Token (SWT) could pull it through. But considering the environment, .NET 4.5.1 / Web Api 2 / OData 3 with Entity Framework in Azure Web Role, I started thinking is this SWT something I should really use or if there is any NEW technologies recently published that could easily pull this through. I don't want to add any unnecessary 3rd party dependencies to the project if the .NET stack already contains something like it.
So, what would be the simplest way of pulling this kind of authentication through without adding unnecessary dependencier to the project.
The solution we are looking for, is only temporary meanwhile we redesign our authentication scheme. So we are looking for something really simple to implement that works with least dependencies that need to be removed later on.
I'm using this in a project I'm currently working on. I use the OAuth 2.0 OWIN Middleware component that ships with Web API 2.0 (if you add a new Web API project with Authentication enabled, it includes the base infrastructure).
You would use the Resource Owner Password Flow as defined in the OAuth 2.0 specification. Basically you request a Token from the Web API OWIN Middleware sending:
client_id - identifies your MVC endpoint
client_secret - identifier your MVC endpoint
username
password
And in response you get a bearer token. The token generating is based upon a claims principal, the OAuth middleware component has predefined hooks for adding claims. This token now needs to be added as authorisation header to each response. On the MVC side you might add this to session so that it's always available to make backend API calls in the context of the user associated with an incoming HTTP request. If you're using WCF Data Services Client, you'll need an authorisation service/manager or similar that you can hook into OnRequestSending and OnResponseReceived events, so that you can insert that bearer token into the HTTP headers.
You can customise the OAuth Middleware component as you need to quite easily, it took a bit of time to figure it out as it's not too well documented, but downloading the Katana source code did help a bit as the source code does have some good documentation.
The nice thing about it all is that you simply need to enable HostAuthenticationFilter and add Authorize attributes on the Web API side and it's ready to go. You can get access to the claims principal object and use claims as identifying pieces of information for your user - e.g. identity, roles, other attributes etc.
To get started, look at http://www.asp.net/vnext/overview/authentication/individual-accounts-in-aspnet-web-api
Also as a wrap, I did consider the use of JSON Web Tokens (JWTs) as there is an OWIN library available for generating and parsing these. The use case here would be that you authenticate, get a JWT back, and then use the JWT to get an OAuth 2.0 bearer token. The JWT is useful if you want to move authentication elsewhere, or if you want to get additional information about the user at the MVC side of things.