My project only supports JWT authorization. Now wanted to add one more authorization which was customized by my company.
The problem is it also sends header same with JWT "Authorization=Bears xxxxxx".
so everytime JWT will automatically authorize basing the Key "Authorization" then failed.
My question is how to disable JWT if one of my authorization succeed.
Thanks.
Related
I'm having a hard time figuring a good way to implement Oauth 2.0 and OpenID Connect authentication alongside an existing internal email+password authentication for a B2B Web app's API using Spring security.
We have a backend REST API that is a Spring Boot servlet application which currently authenticates users with OAuth 1.0 and the password grant. The front-end is an Angular single-page app through which users must log in with their username and password. The API's /oauth/token endpoint then delivers an opaque access token to be used for fetching secured resources that are then displayed within the app.
We'd like to add the possibility to log in using external authentication with OpenID connect, which is a perfect opportunity for switching to OAuth 2.0 and JWT tokens. Our API would then accept JWT tokens it delivered as well as external JWT tokens emitted by accepted issuers.
Reading and validating JWT tokens won't be a problem using Spring security's OAuth Resource Server. However things get complicated with how to make the classic username+password login flow work with JWT tokens.
We thought about delivering JWT access tokens the same way we used to with our old OAuth 1.0 tokens. The thing is, newer OAuth specifications advise against using the password grant, plus it simply isn't supported in the Spring authorization server project we're planning to use. The authorization-code flow w/ PKCE seems like too much for this case as we do not want the back-end API to render a login form but use credentials entered in the existing login form that is part of the single-page app.
I've read a lot about not using OAuth for 1st party login since its primary use is for external authentication, but again, that doesn't apply since we also want 3rd party authentication.
What would be a secure way to implement a Spring boot authorization server that can deliver JWT access tokens to a 1st party client in exchange for a user's credentials, all this using the existing log in page, and given the password grant type no longer being supported?
I thought about implementing a preliminary step that would be a POST request with Basic authentication to a /login endpoint that just returns a 200 HTTP status, then proceeding to the /oauth2/authorize request that would deliver the authorization code immediately without redirecting since my session is authenticated.
I'll be happy to provide more details if needed. Here are the resources I'm using for this project.
What about setting up an authorization-server capable of identity federation?
In such configuration, the authorization-server is responsible for providing with identities, proxying one or more sources (your existing user database for instance, plus maybe Google, Facebook, Github, etc.)
Keycloak does it for instance.
From the client point of view (your Angular app), the authorization-server is used to get:
access-token: put in Authorization header of requests to secured resource-server(s) (can be a JWT or an opaque string, doesn't matter, clients should not try to extract data from access-tokens)
refresh-token: send to authorization-server to renew access-token before it expires
id-token: get user-profile data (email, username, profile picture, etc.)
You should have a look at https://github.com/damienbod/angular-auth-oidc-client for connecting an Angular app to an OIDC authorization-server.
From resource-server point of view, access-tokens are the source ofr setting-up security-context, either by decoding and validating a JWT locally or with token introspection on authorization-server.
Have a look at those tutorials for such resource-servers configuration.
I understand that a resource server will make a call to the authentication server with a token to confirm that it is valid.
However is this token the same Cookie: JSESSIONID?
Oauth 2.0 Bearer tokens are of two types - General tokens(e.g like java uuid string) and JWT tokens.
General tokens will be stored in the authorization server token store along with their scopes, expiry, client ID, UserId and other related information. When client sends request to resource server, Resource server need to reach out authorization server(Spring oauth 2.0) for bearer token validation.
JWT tokens contains information about its expiry along other user information and self sufficient to work in stateless sessions, Here we don't need to validate oauth 2.0 JWT tokens from authorization server.
JSESSIONID Cookie is created by spring security by default, its not related to Bearer token authorization.
Well the standard solution is an introspection request, as in step 14 of this post: https://authguidance.com/2017/09/26/basicspa-oauthworkflow/
Not all solutions are standards based though - and I always recommend capturing the HTTP traffic
Is there a simple way to integrate Firebase Authentication with Spring Security (for a REST service)?
From what I've read, I'll probably need to use a JWT token (obtained via Firebase), use that to authenticate the Spring service, and finally verify the token within the service via Firebase. But I can't find any (simple) documentation on using JWT with Spring Security.
I'd also like to be able to provide an /auth/login endpoint that uses Basic Auth rather than JWT so that I can obtain a JWT token via Firebase using email/password credentials. But this would mean enabling Basic Auth at one endpoint in the service and JWT Auth at all others. Not sure that's possible.
Short answer: no.
Long answer: you should create your own JWT, regardless of Firebase. When you receive a JWT from Firebase, verify its integrity. Then, issue your own based on the data in the token. Then you only need to adapt it to various OAuth providers. This way you can avoid round trips to firebase on each request.
For authenticating the user on each request (stateless auth), you add a filter with highest precedence. From the http request you are filtering, get the JWT and verify its integrity. If it's all good, set the authentication in the SecurityContextHolder.
We are creating Spring Boot REST services that registered third parties can use.
We provided the third parties with a unique API key in JWT format, containing authorizations for that party to the services it can use.
The JWT is securely provided to the third parties and they need to include it in their requests to our API in the Authorization: Bearer header.
There exists new a use case where our API needs to call an other party's OAUTH2 authorized services. They probably are going to use the OAUTH2.0 Authorization Code Flow. This means that the third parties that are calling our API need to be redirected to the Authorization server of the other party to authenticate and get an oauth token generated.
Questions
The question/problem that we have now is, can we refactor our JWT token to include the oauth token from the other party?
And how will the flow look like then?
Or should we proceed with 2 different headers and store our API key JWT token in another header then the Authorization header?
I'm considering using authenticated encrypted JWT tokens to authenticate / authorized access to an ASP.NET Web API application.
Based on what I've read so far, it seems to me like it is an option to generate JWT tokens from a token service and pass them to Web API via the http authorization header.
I have found some good code examples on implementing the JWT creation and consumption (Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan).
I'm trying to understand if I need a full OAuth implementation to support this, or if I can simply pass the tokens along in the auth header.
Assuming the tokens are properly encrypted and signed, is there any inherent security flaw in keeping things simple without having to use OAuth?
Trying to keep things as simple as possible for my needs without compromising security.
It is not that you must always OAuth when you use tokens. But given the fact that your application is a JavaScript app, you would be better off implementing a 3-legged authentication. Thinktecture identity server does support implicit grant. But if the client application getting access to the user credential is not a problem for you, your JavaScript app can get the user ID and password from the user and make a token request from a token issuer ensuring the user ID and password are not stored any where in JavaScript app (including DOM). This request for token can be a simple HTTP POST as well and it does not need to be anything related to OAuth. If your end user will not enter the credentials in the client application, OAuth implicit grant is the way. BTW, you don't need to encrypt JWT. TIS issues signed JWT and that will ensure token integrity. But if you are worried about the confidentiality, you can use HTTPS to both obtain the token as well as present the token.
It looks like you don't really need auth delegation as the one provided by OAuth. Isn't HMAC authentication enough for your scenario ?. With HMAC, you will not have to deal with JWT at all. This is an implementation I made for HMAC authentication for .NET
https://github.com/pcibraro/hawknet
Pablo.