Is it possible to have multiple OAuth servers, in multiple environments, produce and consume tokens that are compatible across all servers?
We have a vendor product that has an inbuilt OAuth server. We wish to perform the OAuth authentication using our existing IdentityServer on premise. We then wish for the access tokens generated via our IdentityServer to be recognised and permitted for access to the vendor product using its inbuilt OAuth.
What would be involved in producing / consuming OAuth tokens across seperate OAuth servers and environments?
It looks like you need Identity Brokering. Check the documentation of an inbuilt OAuth server and IdentityServer and search for this feature.
Related
As far as I understand, applications that we can login with our different accounts use OpenID Connect(A profile of OAuth2.0).
OAuth is for Authorization and OIDC is for authentication(It has ID Token-User Info Endpoint).
So, was it not possible to login to an application from another application account using OAuth before OIDC? (If possible, how?)
If plain OAuth can't be used for authentication, what is/was it used for?
I mean what does it do with 'authorization' exactly?
What does it get from the resource service with the access token?
I have always found the jargon around this unhelpful so I understand your confusion. Here is a plain English summary:
OAuth 2.0
Before OIDC apps used OAuth 2.0 to get tokens, and this involved optional user consent. The process of getting tokens was termed 'delegation'.
In practical terms though all real world OAuth 2.0 providers also included authentication in order for their system to be secure. How authentication was done is not defined in OAuth specifications.
OAuth is primarily about protecting data, where scopes and claims are the mechanisms. These links provide further info:
IAM Primer
Scope Best Practices
Claims Best Practices
OIDC
This just adds some clearer definition around how authentication messages before and after authentication should work:
A client simply includes an openid scope to use OpenID Connect
A client may force a login during a redirect via a prompt=login parameter
A client may request an authentication method via an acr_values parameter
The client receives an ID token (assertion) once authentication is complete, can digitally verify it if required, then use the information in it (eg a user name)
OIDC still does not define how the actual authentication works though.
Use them together
Pretty much all OAuth secured apps (and libraries) these days use both together, so that the authentication and delegation both use standards based solutions. It gives you the best application features and design patterns for doing the security well.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
I am trying to enforce OAuth 2 in Bluemix for a suite of microservices via API Management. Am I right in the assumption that the API Management service will always act as an OAuth 2 Authorization Provider as opposed to only checking the validity of access tokens as an enforcement gateway? The latter would be what I really want to have though.
Ideally I would like to specify my own OAuth Provider Implementation with the means to issue, validate and revoke access tokens. Then having the API Management service as a proxy for my services ensuring that requests coming in carry a valid token.
Reading the documentation I am struggling to understand how the API Management was designed. Could somebody point me to the direction I am looking for, or alternatively help me to understand what the API management's role in the OAuth Flows, listed in the Security Schemes, is?
Thanks.
We are using Apache integration kit (modpf) for integrating web application with PingFederate as SP. We want to use PingFederate as OAuth server as well. Can we use same integration kit to validate access token generated by OAuth server?
or
are there any other libraries to do it?
One such library that I came across is mod_auth_openidc. Has anyone used it for validating access token?
You cannot use the Apache Integration Kit (OpenToken) to validate Oauth Tokens. They are completely different token types and formats.
However, Hans Zandbelt (from Ping Identity) actually wrote the mod_auth_openidc you link to and per its description, it does the following:
"It can also function as an OAuth 2.0 Resource Server, validating access tokens presented by OAuth 2.0 clients against an OAuth 2.0 Authorization Server."
mod_auth_openidc can also be used to provide SSO for Apache websites based on OpenID Connect, and thus substitute the mod_pf module that that provides SSO based on the OpenToken format and protocol. A sample configuration doing both:
OIDCProviderMetadataURL https://localhost:9031/.well-known/openid-configuration
OIDCSSLValidateServer Off
OIDCClientID ac_oic_client
OIDCClientSecret abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication
OIDCRedirectURI https://localhost/example/redirect_uri/
OIDCCryptoPassphrase <password>
OIDCOAuthIntrospectionEndpoint https://localhost:9031/as/token.oauth2
OIDCOAuthIntrospectionEndpointParams grant_type=urn%3Apingidentity.com%3Aoauth2%3Agrant_type%3Avalidate_bearer
OIDCOAuthIntrospectionEndpointAuth client_secret_basic
OIDCOAuthRemoteUserClaim Username
OIDCOAuthSSLValidateServer Off
OIDCOAuthClientID rs_client
OIDCOAuthClientSecret 2Federate
<Location /example/>
AuthType openid-connect
Require valid-user
</Location>
<Location /api>
AuthType oauth20
Require claim scope~\bprofile\b
</Location>
You may want to look at PingAccess for this need. It works alongside PingFederate to handle both browser SSO and OAuth access token validation use cases which may simplify your deployment.
It has benefits over an Apache module in that it allows for centralized administration of access control polices and centralized logout across different applications, which is a typical requirement in an enterprise environment.
For your question "Are there any other libraries to do it?". I take this to mean, is there anything else beyond mod_auth_openidc. There is another option. OAuth is a RESTful service to the PingFederate OAuth Authorization Server (OAS). If all you desire to do is validate the incoming Access Token, then you create a REST API call to the PingFederate OAS to validate the token. Within PingFederate you would need to configure an OAuth client for validation. You could integrate cURL within your application for the REST client and then call the PingFederate OAS. You would have to process the response based on your application or service requirements.
I'm going to be undertaking a large project for a client of mine. I need to write an IDP (identity provider) that will handle single-sign-on to multiple apps by a number of different authentication methods (such as SAML, OAuth, Form-based auth, HTTP Basic auth). I'd also need the ability to add in additional types of authentication as the app grows.
The basic idea would be that we'd have three different components to the app. One would be the IDP. Another would be a data-store that contains user accounts, the apps they want to use, etc. The third would be a GUI front-end that allows users to sign into apps.
It seems that there are some existing gems that handle authentication, like https://github.com/onelogin/ruby-saml and https://github.com/intridea/omniauth. My question is, am I overcomplicating this project -- would I just be able to use existing gems like these to act as the IDP, or is this a project where I'd need to read specs and implement them myself in Ruby?
Using something like SAML toolkit for Ruby on Rails adapted to work with ADFS server, you can integrate with ADFS. Now you can leverage ADFS features:
Interface with Facebook etc. via Azure ACS
Interface with Azure Active Directory and hence SSO to SaaS applications
Azure Active Directory Multi Factor Authentication
BYOD via the Web Applications Proxy
OAuth on ADFS 3.0
and so on. The list is expanding all the time.
Once you hook into these standards. you just inherit all the new features as they are released.