The keycloak javascript adapter - based on their documentation uses authorization code flow but with public client.
I just want to know if its offer the same security as authorization code flow with a private client?
Because, as i was discussing it with my colleagues, we realised something.
The implicit flow is not recommended as the access token will be part of the URL - might be stored in the browser history - but is it also not recommended because it will not be encrypted with the TLS/SSL?
In the authorization code flow of keycloak js adapter, keycloak will redirect to js application with authorization code as url parameter, if someone tried to intercept the call, they will be able to get the authorization code and easily exchange to a token as exchanging token won’t require client secret - is it possible to happen? Then for me, this is as good as implicit flow only, right? Or i might have missed something with keycloak’s documentation.
Also, in keycloak, there are 3 types of client - bearer, private and public - is this specific only to keycloak? Or included in oauth2 specifications?
Related
I am new to implicit flow using OIDC and I am looking for sample code. I could not find anything on internet. Can someone provide links to sample code anywhere.
Any help is really appreciated.
Switching from code flow to implicit flow usually just means changing response_type parameter in your authorization request to token instead of code (or id_token token if you also want the ID token). Then you read the token directly from the response from the Authorization Server (no need to exchange code for token). This should relatively simple to achieve with any OIDC client library, or even just a HTTP client.
Take any OIDC client and change the response_type parameter used by it. If you run any concrete problems I'll be glad to help.
I am trying to understand OAuth2 and its grand types. I just want to know what is the propper grant type flow for authorize a browserless application (a job for example) with a REST API.
authorization_code and implicit flow require user interaction (writing the username and password in the browser), hence both are not suitable for browserless authorization.
client_credentials could work, but there is no user in the authorization process, so what happend if the REST API needs to know the user to check for permission/roles/scopes? Maybe creating a client for each user could work, but sound like a bad thing.
passwordgrant type will be deprecated in the OAuth2.1 specification, so this is not an option.
You may thing that OAuth2 is not the framework to use in this case, because you don't need authorization delegation, but what about if you have both (it is so common), a single page application where you could delegate authorization and also a REST API. What is the propper way to authorize a REST API using Oauth2?
Given that this is a background job, Client Credentials Grant is the best OAuth 2.0 related approach. And, it does not use any end user credential (End users and clients are two different entities with respect to OAuth 2.0). Hence you simply need a credential for the given client application.
Other approach is to enable API tokens. But this will require a manual step where you will insert the token to the background job. Again, this is independent from any end users.
p.s - Read about roles (i.e - client vs end-user/resource owner) - OAuth 2.0 roles
We had an web application that already using form-login provided by spring-security, say, ERP. Now we are considering make ERP as an oauth2 authorization server to authorize other internal services.
The ERP still serving its business and all access are required to be authorized, but doesn't based on access token so I think it is not an oauth2 client. It does NOT serve as an Resource Server, neither.
I have read many article about how to setup oauth2 authorization server and develop an application using it. According to this comment I feel it is possible to make ERP authorizing other services without explicit setup a standalone authorization server (it's our final goal but not now):
Within the context of OAuth2, we can break things up according to the component you're implementing:
Client app: it's likely that server based OAuth2 Client app already uses HttpSession and therefore it makes sense to use Spring Session and benefit from all the goodies it brings
Resource Server app: since this component provides a stateless API that's authenticated against using an Access Token as a bearer, the HttpSession is not used and therefore Spring Session isn't suitable as well
Authorization Server app: it's highly likely that this already uses HttpSession so similarly like with OAuth2 Client app, it makes sense to use Spring Session and benefit from all the goodies it brings
What I'm going to do is add the #EnableAuthorizationServer into config, but I have no idea what's the next step.
My question is can I convert an existing application into an authorization server while keeping its original service unchanged? Where and How should I start?
I just found it's not that hard to integrate OAuth2 into existing system, below is what I did to make it work.
In short: EnableAuthorizationServer won't break anything exists, but they don't coming from nothing, either.
When I put on the EnableAuthorizationServer, spring-security-oauth2 gives me following endpoing:
/oauth/authorize
/oauth/check_token
/oauth/token
/oauth/confirm_access
/oauth/error
Those endpoints provide necessary functions to make OAuth2 works, and I just need to apply access control onto those endpoints with existing form login mechanism (probable not the check_token one).
Since this system didn't act as resource-server role, the authorization part is done.
When I am trying to understand OAuth2 client, I am confused about why we have two different filters
I attempted to integrate with Github. Here are my observations
OAuth2AuthorizationCodeGrantFilter sound like a filter that exchanges authorization code for access token, but when I keep debug point it does not do that
OAuth2LoginAuthenticationFilter sounds somewhat like it does login somehow, but this filter exchanges auth code to access token instead of above
I'm not sure why this is the case, as the first class name implies some strong correlation to authorization code
Also, Whats is the difference between OAuth2LoginConfigurer & OAuth2ClientConfigurer
Looks like OAuth2LoginConfigurer configures OAuth2LoginAuthenticationFilter, while OAuth2ClientConfigurer configures OAuth2AuthorizationCodeGrantFilter
Can someone explain what each of them does & in which scenarios they are applicable?
Thanks
This is well documented in the Spring Security reference.
OAuth 2.0 Login
OAuth 2.0 Client
As well, in the javadoc:
OAuth2LoginAuthenticationFilter
OAuth2AuthorizationCodeGrantFilter
At a high level:
http.oauth2Login() is an implementation of OpenID Connect Authentication using the Authorization Code Flow
http.oauth2Client().authorizationCodeGrant() is an implementation of OAuth 2.0 Authorization Code grant
After reading the article How To Control User Identity Within Microservices I've been trying to implement such access control scheme (Value and Reference Tokens), but after going through multiple other topics and examples in GitHub related to Spring Security + OAuth + Zuul, I couldn't find concrete examples on how this can be achieved. All the examples that involve JWT return User Details when the token is returned, and that is what I would like to avoid. The User Details should never reach the Client directly but should be passed to the backend services instead. The tutorial Spring Security + AngularJs has a lot of information on how to evolve an application towards a secure one, but uses an Access Token or mentions the possibility of getting the User Details directly via JWT.
This SO question, Using Zuul as an authentication gateway by #phoenix7360, is exactly the approach I've been trying to implement but it only supplies a brief overview of the configuration required to carry out this kind of security approach for microservices. Please refer to the image in this question for a clear picture of how it would go.
I can't fully get my head around how the Zuul Pre-Filter should be configured and what the Authorization Server's configuration should look like. As stated in both the article and the SO question, the flow would go something like this:
External (HTTPS)
The client authenticates against OAuth2 Server
OAuth Server returns an opaque Access Token (a UUID with no other information)
The client sends the request to the API Gateway with the Access Token in the Authorization header
API Gateway requests User Details to the OAuth Server with the Access Token in the Authorization header
OAuth Server checks the Access Token is valid and returns User Information in JSON format
Internal (HTTP/S)
API Gateway creates a JWT with User Details and signs it with a private key
API Gateway adds the JWT to request and forwards it to Resource Server
Resource Server verifies the JWT using API Gateway's public key
Note: API Gateway should return an error if OAuth Server indicates Access Token is no longer valid.
How would the ZuulFilter work? Does a new request need to be issued against the OAuth Server (for instance, via RestTemplate), or are these schemes supported with the current implementation? Is there any particular configuration required for the JavaConfig classes for both OAuth and Zuul? If someone knows of a working example that would be really helpful and would be great for future reference regarding this topic.
I'm using Spring Boot (1.4.0-M3) + Spring OAuth + Spring Cloud (Eureka, Ribbon, Zuul)
I know this question is very similar to the one linked previously, and if this is not the right way of doing it I apologize, but I thought a new thread would be better than asking for help on a SO thread that aimed at solving another problem.
Thanks in advance!
JHipster does a pretty good job in handling this issue. If I want to tell the login process briefly, first you do login, in time you fetch every information you need to pass to your below services (such as username,email,etc) then you pass them to your microservices.
you can see the link below from okta for more information
https://developer.okta.com/blog/2018/03/01/develop-microservices-jhipster-oauth