Since mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that authenticates users against an OpenID Connect Provider. If OpenID Connect Provider supports STS(Security Token Service) does mod_auth_openidc is supported for that.I couldn't find any resources which explains about this.
No, assuming you refer to the WS-Trust STS.
Update: there's a separate module https://github.com/zmartzone/mod_sts that supports various token exchange protocols including WS-Trust.
Related
We are planning to use OpenID Connect / OAuth2 to handle access to a list of resource servers.
We want to use JWT as access token when a user is going to call one of the resource servers. The access token will be issued by an auth server in our landscape according to OpenId Connect / OAuth2 standards. Access will be granted or rejected to the calling user based on the JWT access token.
The standards are new for us so we are still reading and understanding.
We are currently searching for an option to do a lookup of the resource servers with a call to auth server. We would like to use it in order to simplify the clients.
Is there any option available in OpenId Connect / OAuth2 to help clients finding the available resource server? Is there any endpoint available in auth server to do that? Or can the answer with the JWT be enhanced to return the list of the resource servers?
Thanks in advance
Thorsten
With the use of JWT, there is no need to go for one extra validation from the authorization server. Token & its claims should be enough to validate the access rights. You can customized the token claims as per the needs.
An Authorization Server does not know the list of APIs, since APIs are not usually registered as clients. There are some related concepts though. The IAM Primer article has a good overview on how these concepts fit together.
Each API covers an area of data and this maps neatly to the OAuth Scopes included in access tokens.
Each API has an audience, such as api.mycompany.com, which maps to the aud claim in an access token. This can enable related APIs to forward the same access token to each other and securely maintain the original caller's identity.
An API gateway is usually hosted in front of APIs, as a hosting best practice. This enables clients to use a single, easy to manage, API base URL, such as https://api.mycompany.com, followed by a logical path.
What is the difference between OAuth 2.0 and Auth0? Which one should I use to develop the authentication system?
OAuth 2.0 is a standardized authorization protocol, Auth0 is a company that sells an identity management platform with authentication and authorization services that implements the OAuth2 protocol (among others).
OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.
Auth0 is an organisation, who manages Universal Identity Platform for web, mobile and IoT can handle any of them — B2C, B2B, B2E, or a combination.
Source
In case if you cannot understand any of above,
OAuth 2 - is a standard or protocol to implement authorization for any kind of software (windows, mobile or web)
Auth0 - is a software product (cloud and on-prem), that implements the OAuth2 protocol. You can use Auth0 to simplify your
authentication and authorization requirements.
We mainly use auth 2.0 for session based security management at server side. OAuth 2.0 is an authorisation framework that enables a third-party application to obtain limited access to resources the end-user owns. It is about resource access and sharing. While https://auth0.com is a company that sells an identity management platform for authentication related task. So with the help of auth0.com services an app developer don't need to write code for login/registration/social login and its not needed to think about its security. Complete user management task manages by auth0 organisation.
What Identity Provider are you aiming to use?
Auth0, identityserver, ADFS 4.0 etc. all support the OAuth stack.
Using implicit OAuth flow you can connect your Angular application to any of these.
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 constantly get confused by OpenID Connect and Oauth2, and I read this article and get a sense that Google is using OpenID Connect https://auth0.com/docs/oauth-web-protocol (but I remember google used Oauth2 as providing auth service to 3rd parties), see the following quote
Auth0 supports the OpenID Connect / OAuth2 Login protocol. This is the protocol used by companies like Google, Facebook and Microsoft among others so there are plenty of libraries implementing it on various platforms.
Moreover, the above URL seems to say Auth0 is using OpenID (rather Oauth)? See the following quote:
GET https://YOUR_NAMESPACE/authorize/?
response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=http://YOUR_APP/callback
&state=VALUE_THAT_SURVIVES_REDIRECTS
&scope=openid
http://openid.net/specs/openid-connect-basic-1_0.html
OpenID Connect is basically authentication built on top of OAuth 2.0.
OAuth 2.0 by itself didn't standardise authentication (just authorization) and the confusion you have likely comes from the fact that each of the companies that are now switching to OIDC previously had already poured their own "authentication sauce" on over their OAuth 2.0 implementations. In practice this meant that each had their own set of scopes and their own version of what is a standard /userinfo endpoint in OIDC, but the authorization mechanism in all cases (including OIDC) is based on OAuth 2.0.
To wrap up by answering your question: Yes, both of the endpoints you mention support OpenID Connect.
I have been using OAuth resource owner credential flow previously for authorization.
However I would now like to consider using openid connect in pace of this, for authentication and authorization, and was wondering if the resource owner credential flow is supported in openid connect.
Yes, OpenID Connect supports all OAuth 2.0 grant types including Resource Owner Password Credentials Grant and Client Credentials Grant.
As we know, Authorization Code Grant and Implicit Grant are typical 3-legged flows including interaction between a client, an authorization server and a user. While the Resource Owner Password Credential Grant and Client Credential Grant are 2-legged which means the client uses pre-authorized scopes so that no interaction with the user is necessary, removing the need to perform one of the legs in the typical flow.
Here is a reference: Configuring an OpenID Connect Provider to enable 2-legged OAuth requests
The answer is YES. It is not explicit in the specification but OpenID Connect supports all OAuth 2.0 flows since it is an extension of OAuth 2.0.
The spec talks about the flows that involve browser redirect as they are more common, more secure and less brittle given that resource owner credentials only supports username and password and is only in the OAuth 2 spec for backwards compatibility.
In true SSO systems you'd want to abstract away from the method of authenticating the user at the OP/IDP. Involving a browser is a way to do that. In the Resource Owner Password Credentials flow the client "sees" the username/password of the Resource Owner unlike the other flows, which defeats the primary purpose of a federated SSO protocol like OpenID Connect where authentication mechanisms and credentials should be independent from the client/app. For that reason you won't see much use of ROPC in OpenID Connect, with an exception perhaps in intra-enterprise use cases.
But your mileage may vary wrt. support in specific OP/AS software and client libraries.
Yes. I also was finding answer for same question sometimes back. According to the OpenId Connect specification, It is recommended to use authorization code and implicit grant types for OpenId Connect requests. But it is not mentioned that other grant types can not be used. Therefore you can use any other grant types for OpenId Connect authentication request. There is some mail from the openid connect group, which has been discussed on this. Please find it from here. If your OAuth2 Authorization server supports it, I guess that it is fine to use it. As i know, most of the Authorization servers support it, as an example from here