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
Related
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.
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
We have a ADFS server farm running version 3.0. Right now, we have it enabled to authenticate 3rd party vendor applications. We are planning to leverage this existing server farm to generate a JWT token for it to be consumed by our in-house custom applications. Does anyone know the steps to be followed for generating a JWT token which returns all the AD groups associated with the user?
Configuration - Windows Server 2012 R2, ADFS 3.0.
Can use either OAuth or SAML.
Please help.
This link should help.
Note that you should really use OpenID Connect for authentication but that's not available on ADFS 3.0. Also the user case for ADFS 3.0 OAuth is web API not application.
We are already using CAS for single sign on for several web applications that we are hosting. Now we are going to deploy several HTTP/REST services in our network and those need authentication and authorization.
Would it be a good idea to combine CAS with OAuth ?
Users would still use CAS for SSO, but additionally login procedure would issue OAuth ticket that would be used to access REST services.
REST services can be protected via CAS proxy authn. Additionally, they can be integrated with OAuth. CAS provides both OAuth and OIDC protocol functionality as well.
That's certainly valid. OAuth 2.0 doesn't specify/dictate how the user (Resource Owner) is authenticated and CAS/SSO is fine for that. Effectively you'd be leveraging a CASified Authorization Server so that the Resource Owner authenticates with CAS to the Authorization Server, which is "just" an application to the CAS SSO system. The Authorization Server would then issue an access token down to the Client so that the Client can use that access token to access the protected resources i.e. the REST services.
I am looking for fittings ends to our SSO puzzle.
Currently we have an OpenLDAP behind WSO2 Identity Provider. A client (Service Provider) redirects authorization to the IP (OAuth2) and recieves an access_token.
All fine.
Next step is to validate this token on another Service Provider, in this case a reverse proxy (Apache or Nginx) residing on another EC2 instance, which protects a number of unprotected 3rd party applications (3rd party in the sense that we can't touch source code, but do the hosting our selves). Which tools do serve this request?
Am am aware that the OAuth2 spec leaves a hiatus here and that there is draft which adds a /introspect call to validate this token. I also know that pingidentity implements this draft as part of there Apache module (https://github.com/pingidentity/mod_auth_openidc).
I am just wondering how to implement this on the WSO2-IS side, as I don't find documentation.
*bonus: we also hit several errors while deploying WSO2 (SQL errors) and using it (https://wso2.org/jira/browse/IDENTITY-3009) which made us a bit distrusting about the product.
Oauth2 token validate may be performed with a SOAP call to
{WSO2_IS}/services/OAuth2TokenValidationService.OAuth2TokenValidationServiceHttpsSoap11Endpoint/
The response will include details regarding token validity and JWT claims.