I have a web api application which implements the Resource Owner Password flow from OAuth specification. Everything works correctly.
Actually I configure everything in my WebApiConfig class by using an Authentication filter like this
// Configure Web API to use only bearer token authentication.
config.SuppressDefaultHostAuthentication();
config.Filters.Add( new HostAuthenticationFilter( OAuthDefaults.AuthenticationType ) );
As some of my customer asked for a different method of authentication I am evaluating to add a couple of features to my services but stil did not have clear how those features can work together.
In particular I cam across a link which explain in very easy words how to implement a HMAC authentication in web api.
Can I implement this authentication method and let the client to choose which one he want to use? Do they can cohesist together?
Yes, your web api service can send back multiple schemes in the WWW-Authenticate challenge. In your case it can send back 'bearer' and 'hmac' for example.
See also this question for more info on using multiple schemes.
BTW, it's not your web api service that supports Resource Owner Password flow. The client uses this flow to get a token from the authorization server that it can use in a bearer scheme with your service (resource server). HTH.
Related
I want to develop an authentication mechanism for 3rd party applications using keycloak initial access tokens. But I want to do this only by using the access tokens that I have generated in the keycloak. For example, I will give a generated token to the user and allow him to log into the application. Is this possible? How can i do that?
Initial Access Token
First, I'm not sure it is a good idea to use "initial access token" for authorizing requests to your own resources. It might even not be allowed. As per the doc:
An initial access token can only be used to create clients
Second, don't use keycloak libs for Spring as suggested in other answer. It is very deprecated.
Last, a REST API secured with Oauth2 is a resource-server (and not a client). As so, the dependency should be spring-boot-starter-oauth2-resource-server. Spring doc is pretty extensive on the subject. You can also have a look at those tutorials for resource-server configuration (and OAuth2 definitions).
Once the resource-server (Spring REST API) is configured, clients will have to authorize their requests as normal for OAuth2: provide with an Authorization header containing a Bearer access-token (a JWT issued by Keycloak to the client with one of standard flows: client-credentials or authorization-code depending you need to authorize the client itself or a user behind it).
Edit
I might have misunderstood your need. If what you want is having new clients register themself programmatically on your Keycloak instance, then those clients will just issue a REST request to Keycloak server API with the "initial access token" in Authorization header as normal.
Once registered, those clients will be able to call you resource-servers as described in my initial answer.
I have some questions because I don't understand well how implement authentication flow.
Reading some docs I found image below
Now, I understand the access token and refresh token, but I don't think I understand how to implement it.
I have a project where frontend is angular and backend is node.js koa with microservices architecture and gateways in front of them.
I can use auth0 like oauth2 authorization server with users stored inside?
How? In auth0 docs there are tons of instructions and I cannot understand which is right for me.
I have to intercept login, logout and sign up by gateway and redirect to auth0 or I have to do this inside my user microservice?
Does a user table make sense in my project(s) where there are also personal info table and company table?
Is in this way the authorization server sso for all my company projects?
Can I add external company's SSO?
Can I add Google sign in?
You can follow Auth0 Angular Quickstarts to implement your scenario. It exactly shows step by step implementation. https://auth0.com/docs/quickstart/spa/angular2/01-login
From architecture level, you are doing following:
Frontend application (angular) uses auth0-spa-js to implement Authorization Code flow + PKCE to implement login flow. It simply performs user authentication and obtain a token which request API scope as well. To request API permission, add the audience parameter when initiating the login flow.
Once you obtain the token, access token can be used to call your backend API.
In the backend server , you should implement API authorization (It validates the access token and check token have necessary scopes/ permission). https://auth0.com/docs/quickstart/backend/nodejs/01-authorization
Above API authoriazatio quickstart uses express middleware. This blog post explains how to do the same in koa . https://auth0.com/blog/building-and-securing-a-koa-and-angular2-app-with-jwt/
you have a very broad architectural implementation question for your specific organization case.
I would recommend you follow the below user management model which takes care of
Simple API for Authentication, Registration and User Management using NodeJS + Koa + Passport combination.
You can deploy the API to Heroku and test the API using Postman.
You can use the NodeJS Global Error Handler Middleware and you do not have to implement any reduntant local error handler.
As a best practice, use the node JWT middleware that checks the JWT token received in the http request from the client is valid before allowing access to the API, if the token is invalid a "401 Unauthorized" response is sent to the client. This JWT API authorization can be done at your gateway level itself before your microservices.
Finally the Koa + Passport user service contains the core business logic for user authentication and uses Koa-Redis for session management in the node api, it encapsulates all interaction with the mongoose user model and exposes a simple set of methods which are used by the users controller.
Moroever Koa + Passport supports Single sign-on with OpenID and OAuth which answers your other question related to SSO.
Here too you can find that KOA is best suited for microservices as you have already chosen the same. Overlaying authentication + user management using the same infrastructure will prove to be very versatile and extensible.
https://mherman.org/blog/user-authentication-with-passport-and-koa/
In order to connect to an external SSO provider, you could use the nodejs oauth2 client api as follows which allows you to connect your node backend to connect to an external SSO server.
https://www.npmjs.com/package/client-oauth2
For SSO using Google/Gmail, it is best to use SAML based SSO provided by google.
Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. In return, the Identity provider generates an authentication assertion, which indicates that a user has been authenticated.
SAML is a standard single sign-on (SSO) format. Authentication information is exchanged through digitally signed XML documents. It's a complex single sign-on (SSO) implementation that enables seamless authentication, mostly between businesses and enterprises.
below link provides details of how to setup a SAML/SSO service into google from your application.
https://support.google.com/a/answer/6087519?hl=en
I have to design a mobile application that interacts with a provided API to exchange data and info, and I've read about API security, Oauth 2, tokens, .... etc, but something still not clear to me, the following are the important points:
API provided by a 3rd party as a black box, no security implemented,
so you can query for data belongs to any user.
a user should use our application, sign in with a user/password and get access to his data only. (must be very
secure, because we should pay a lot if security was broken)
the solution needs to be implemented and self-hosted, not from a third party or cloud provider.
example of an API call:
....base url...../{subscriber-ID}/offers
the above call get the suitable offers for a subscriber whose ID is {subscriber-ID}, so obviously, without security, I can query offers for any subscriber, but my goal is to link between user/password and querying only data related to the desired user.
I read a lot, but I'm confused since I'm new to API security.
so where should I start? how can I benefit from Oauth 2 in my case? just need a roadmap, not how to implement.
oAuth2 using spring security is a solution for this requirement.
There are 4 grant types in oAuth2 which is meant for different scenarios.
client credential : the consumer (app) make calls to back-end using the bearer token created using apikey(or clientId) and secret only. Mostly used for anonymous calls where generic information is retrieved.
Resource owner password credential (ROPC) : the consumer (app) make calls using the bearer token created using apikey, secret, username and password. Mostly used when you(your authorization server) already know the users(user database is handled in your own system).
Authorization code : the consumer (app) make calls using the bearer token created using an authorization code. The authorization code is provided by a 3rd party (which actually has/manages the logged in user data) and the created authorization code linked to the logged in user. Google and Facebook log in for various sites is a typical example. Facebook/Google gives an authorization code for those websites and they exchange that code for a token.
Implicit grant : Mix of password credential and authorization code. Instead of authorization code, you get a bearer token from the 3rd party authorization server.
I have been searching a lot for a simple sample code for an authorization server, but never found one. So, I tried to create it myself which you can find here : https://github.com/abbinv/oauth2Server. Only ROPC and Client Credential is implemented.
It is not a 'beautiful' code. But i think you will get the basics.
I have APIs. Some of them are limited to access from third party applications by OAuth.
I also have a web application. Users can login and see their private information.
The API is called from the web application too. My question is what is the good way to access the API with security measures.
1. Third party applications -> OAuth
2. My own web application -> ???
My web application uses session id for authentication. I guess that transferring the session id with HTTP header may be good way but I don't have a confidence.
For exmaple...
$ curl -X PUT \
-H "X-Sample-Application-Id: "My own web application's ID" \
-H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \
If API receive this request, use session for authentication instead of oauth and identify the user....
Any help will be appreciated.
Thanks,
.. I found similar questions
Questions About Consuming Your Own API with OAuth
Update1
Some say JWT(Json Web Token) is good.
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html
Update2
I may be able to use OAuth's "Resource Owner Password Credentials"
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html
Or... "Client Credentials grant" looks much better.
I'm going to elaborate a bit on this, because it's a good question, and there is a lot of confusion around it -- so bear with me here.
If the API you are trying to protect is going to exclusively be used by individuals for server-side apps, and not third-party developers, I'd highly, HIGHLY recommend you use HTTP Basic Authentication to secure your API service.
The way this works is super straight forward:
For your user(s), generate API Key pair(s) that consist of an ID and Secret. API keys are synonymous with username/passwords. Just generate random ID / Secret values using a UUID library.
When you authenticate against your API service, supply those API credentials in the HTTP Authorization header to identify yourself. Here's how it looks using curl:
$ curl --user my-api-keyid:my-api-key-secret https://api.myservice.com/blah
What's great about Basic Auth is that:
It's very simple to implement.
It's a well defined standard.
As long as you are making requests over HTTPS, and you don't publicize your API keys, you should be safe.
Now -- if you're building an API service where you want to authenticate users from a variety of environments (not just server side applications), you really need to use the OAuth2 protocol.
This is what it was designed for.
The OAuth2 protocol can authenticate users in a variety of ways -- but as a result, is quite complicated. Adding OAuth to your site can be a challenge, even if you're using popular libraries / etc.
Here's how OAuth works (a quick breakdown):
The Password Grant
The Password flow in OAuth is where you exchange a username/password for an Access Token (usually a JWT). You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what most people do when building SPAs with Angular / React, as well as mobile apps.
The Client Credentials Grant
The Client Credentials flow is where you exchange an API key (just like basic auth) for an Access Token. You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what people do when building server side apps with OAuth.
The Implicit Grant
This flow is what you see when you log into some place like Facebook. You click a button, are redirected to some other site to authenticate / accept permissions, and finally you're returned back to the main site with an Acccess Token that you use to identify yourself. This is NOT ideal for API services.
The Authorization Code Grant
This flow is exactly like the implicit flow, except you get back an authorization code that you then EXCHANGE for an Access Token that you use to identify yourself. This is NOT ideal for API services. It's slightly more secure.
If you are planning on going with OAuth because of your use case, I'd highly recommend checking out an authentication provider like Stormpath. They automate a lot of this stuff, and solve a lot of complexities around OAuth.
Otherwise, give Basic Auth a go!
I have an API that requires authentication via OAuth 2.0. I originally anticipated using HWIOAuthBundle, however from investigation this is more to do with hooking up 3rd parties into Symfony's security/auth mechanism and does not provide the required mechanism for validating OAuth 2.0 Authorization headers.
I then found some information about FOSOAuthServerBundle which enables an application to become it's own OAuth 2.0 provider as well as providing the required security mechanisms to validate Authorization headers.
However the problem is that I would like integrate the OAuth 2.0 provider (authorisation server) in an external application (which contains the user base) and not include it within the API. Which will provide some mechanism for performing the token verification against this external app via (another) RESTful API.
Points:
RESTful API requires OAuth 2.0 authentication.
OAuth 2.0 authorisation server to be situated in a separate application.
I feel I should use Implicit grant and call the authorization server on each request to validate that the token is correct.
Is my thinking correct?
As far as I undesratnd your requirement, you require to authenticate your APIs via external OAuth Authorization Server:
Client needs to provide the access token retrieved in the above steps
along with the request to access the protected resource. Access token
will be sent as an authorization parameter in the request header.
Server will authenticate the request based on the token.
If token is valid then client will get an access to protected resource otherwise access is denied.
here is an example which might help you to achieve your requirement. Check this document .
Or simply, you can do with Jersey and Oauth
Also, you can check Apache Oltu and figure out the way to achieve your requirement.
A lot of the big companies like Google, Facebook etc have a separate authorization server from the API server. Check out Google's OAuth authorization flow below
You can also check Google's OAuth Documentation for the details.
So all you would need to do is implement a OAuth Provider so that you can authorize against that provider. There's a list of libraries available on the OAuth website: http://oauth.net/code. You can specifically look here; there is an example for running an OAuth Service Provider in Java.
oAuth can most definitely be a server other than your application server. Below is a picture of what the authentication sequence would look like:
-- Obviously, if the forum can't decode or validate the token, the forum would return a 401 status code instead of a 200 status code.
As long as your oAuth server & the Forum share the same public key, you're more than okay with splitting your oAuth Server & your application.
In fact, take a look at jwt.io. Paste the token you get from the oAuth server into there. It should be able to decode the token right away. Then, you can put your public key into the 'secret' text box to verify the token is verified.
Your application (Forum, in this example) should be able to do the same:
1) Grab the token from the Authorization header of the request
2) Decode the token
3) Check the expire date
4) Verify the token using the oAuth's public key
5) Return successful status code or a failure status code