I've connected Okta with Spring Security for server-to-server communication and everything is working as expected(client credentials approach). However, I need to support JWT validation in resource servers issued from 2 different authorization servers(by Okta) in the resource server. How can I support this in Spring Boot or any idea how to handle it manually maybe. I'm using Okta spring boot starter to make validation etc for JWT and added the following properties for fetching keys for JWT validation.
okta.oauth2.issuer=https://{account_number}.okta.com/oauth2/xyz
okta.oauth2.audience=test
Now, the second server has a different issuer URL, but I want to support JWTs created from the second authorization server as well. Authorization servers are different because they had different scopes to support.
Any answer will be appreciated. Thanks in advance.
Related
I have an Authorization Server with Spring Security 5. It supports Authorization Code, Authorization Code with PKCE, Implicit Grant and Client Credentials flows from the OAuth 2.0 authentication framework for it's clients. This Spring Security 5 Auth Server is also connected with a database with users information and it's passwords hashing. Currently the Auth user validates users credentials from the login page using the users tables from the database.
Right now I need to setup an AWS Cognito User Pool and use the same users already stored in the database. My intention is to use the Spring Security Auth Server as an OIDC Identity Provider for my user pool in AWS Cognito.
Is this possible?
AWS Cognito can act as an Authorization Server, meaning your apps will get AWS tokens. In this case you add Spring as an OpenID Connect IDP, similar to my blog post which used Okta as an IDP. This could be quite an impactful change though, since you may not be able to make Cognito access tokens contain any custom values.
Alternatively you can do it the other way round, in which case your apps will receive Spring issued tokens. I would expect the integration to basically work, whichever way round you do it, though you could experience some annoyances.
An important factor is how your APIs / back end will identify users from access tokens after this change, since Cognito and Spring will use different subject claims in access tokens. In case relevant, this detailed Curity article discusses migrations and user IDs.
I have a authorization server which generates and store bearer tokens for username and password log in using the oauth2 password grant. I want to integrate social sign in (Google and facebook) to my existing authorization server. Since my other resources are protected by authorization server how do I generate a Bearer tokens for google/facebook signed in users ? so i can access my protected resources using that token.
Note: Bearer tokens are stored in mysql db. (Using JdbcTokenStore)
Since I already have password grant implementation, I'am glad if you can give me direction to do with the current authorization service using spring-boot and spring security.
Thank you.
There are 2 main ways to implement this:
Federation, so that the Authorization Server manages integration with social identity providers
Handle different providers in your apps, which will add complexity to both your UIs and APIs
Personally I much prefer the first option, which only requires configuration changes - and no code changes in UIs and APIs. My Federated Logins Blog Post may help you to understand your architectural choices.
It is worth doing some early technical testing to see if these steps work:
Adding an OAuth web client to Google / Facebook
Adding an Identity Provider to your Authorization Server
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
Configuration: We are using Identity Server 3 with a Web API 2 application, a mobile phone application and an upstream identity server.
Problem: The upstream identity server supports OAuth2 but not OIDC.
Question 1: Does Identity Server 3 support OAuth2 without OIDC to the upstream identity server?
Question 2: Do I need additional configuration to make OAuth2 work without OIDC?
Just to give a bit of understanding about OAuth2 and OIDC:
OIDC is extension of OAuth2. OAuth 2 isn’t about authentication. It’s all about authorization. https://www.rfc-editor.org/rfc/rfc6749 OIDC is a simple layer on top of the OAuth 2 protocol that deals with the end user. http://openid.net/specs/openid-connect-core-1_0.html
I’m not exactly sure about your implementation detail but Identity Server 3 supports OAuth2 as well as OIDC and it all depends how the client is setup (flow) and what the client asks in terms of a “ResponseType” as part of a token request to Identity Server 3.
I know this may not be an answer to your 2 questions but I think you need to think of the interaction between the Client (mobile phone application), Identity Server 3, and the Upstream Identity Server. If the Upstream Identity Server does not support OIDC then it does not care about authentication of the end user and therefore I would think that it only requires some sort of clientId/clientsecret that could be passed as part of the request to get a token? Machine to machine (Client Credential Flow). So maybe your mobile phone application calls the Upstream Identity Server in a different fashion then it does Identity Server 3? Hope this helped a bit. Cheers
I have a SP(Service Provider implemented using Spring SAML), I want the SP will send the authentication SAML token to another service application .Now I need validate(only) the token against the IDP at service apilcation end. How can I achieve this?
Any help will be apreciated
There is no mechanism in the standard SAML profiles which allows validation of issued SAML assertions against IDP servers. Validation is typically done by recipients of the tokens - by validating XML signature on the assertion and verifying it was performed using a trusted certificate.
There are also additional standards which prescribe issuing and usage of SAML assertions for such use-cases, for example WS-Trust, but it tends to get complex pretty fast.
You might also want to look into OAuth 2.0 standard, which is a good way to achieve machine-to-machine authentication, performed on-behalf of a user.