Google had implemented OpenID Discovery Spec at https://accounts.google.com/.well-known/openid-configuration which allows developers and users to find the necessary URLs and keys for OpenID authentication.
I was wondering what the Facebook and possibly other (e.g. Microsoft Live) equivalents are so I can use Facebook and others in a standard fashion.
SalesForce also has a discovery URL https://login.salesforce.com/.well-known/openid-configuration
Here is OpenID Configuration For Facebook
https://www.facebook.com/.well-known/openid-configuration/
Facebook's login mechanism/protocol is not based on OpenID Connect. Facebook uses a proprietary extension of OAuth 2.0 but it is not the standardized one that OpenID Connect specifies. Hence there's no point in expecting Facebook to publish OpenID Connect Discovery documents, unlike Google and Salesforce that do adhere to the standard.
Here is the OpenID Connect Discovery URL for Microsoft Azure AD:
https://login.windows.net/common/.well-known/openid-configuration
More information here.
Related
I am trying to find it in the developer doc but no luck:
https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/
Does GitHub expose a discovery endpoint for openid?
Appears Github only supports OAuth and not OpenID Connect.
This implies that only OAuth Client's are delegated access to a resources which belong to another.
I have added an identity provider with OpenID connect V1.0 and used Google endpoints. I have provided the option ?hd=X.com(https://accounts.google.com/o/oauth2/v2/auth?hd=X.com) to restrict the login, but as per the google doc, it says HD is an optional parameter. How to validate if the token received from Google after login from keycloak perspective and restrict login?
For anyone still curious about this answer, as of KC 11.0.0 the KeyCloak server is explicit that it will validate the response from Google matches the hd parameter you set in KeyCloak, as seen here:
I have a blockchain network built using Hyperledger Composer, started the Composer Rest Server and generated Java client code from the Open API spec to consume the REST Api. I have looked at the documentation to enable authentication and multi user mode. I already have authentication in my web application. How would I go about granting access to the user to interact with the blockchain after they sign into my web app?
Thanks.
Can you please tell us what strategy are you using for your web-application authentication?
Recently updated documentation # https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication
The REST server uses the open source Passport authentication middleware.
Administrators of the REST server must select Passport strategies to
authenticate clients. Multiple Passport strategies can be selected, allowing
clients of the REST server to select a preferred authentication mechanism.
Passport includes a wide range of strategies (300+ at the time of writing),
including a mix of social media (Google, Facebook, Twitter) and enterprise
(SAML, LDAP) strategies.
You need to configure an appropriate passport-strategy to generate the access_token that will be used by REST API SERVER.
We are using WS02 ESB to create cloud app connections to our platform.
Our current issue: If we want to connect to any app (take salesforce as an example), we need the following details:
UserName
Password
Token
As a pre-requisite, the salesforce account should be API enabled.
We thought of using SSO in backend to avoid (3) and (4), but it's not possible with SAML(SSO).We are looking into ways to connect and publish data to salesforce with just Username(1)/Password(2). In this process of evaluation, SSO is one of the options
Any suggestions on how we can get the below details for APPS would be much appreciated!
• How do we get Token
• How we accept only the accounts where API's are enabled.
As far as I understand what you need is to call an SAML SSO secured backend app (i.e :- salesforce)?. If its the case you may use WSO2 Identity server for this purpose.You can obtain tokens from it.Further You can use this guide and this to call SAML secured backends through ESB.
Hope this helps.
You can use ESB Connectors to connect with Salesforce API. You can find Salesforce SOAP connector (which uses the username, password, and security token for authentication), Salesforce REST connector (which uses OAuth protocol) and Salesforce bulk connector (which also uses OAuth protocol) at WSO2 Store.
In WSO2 we have 150+ ESB connectors to communicate with third party API's via ESB. You can download the connector from WSO2 Store and can follow the documentation here. In connectors we have the mechanism to connect the third party API's(For Example In salesforce SOAP based connector we had the username password flow and for Salesforce REST connector we had oAuth 2.0 flow and the username password flow). In all connectors you just call the init method to get the Token to access the API.
I’m having trouble understanding OpenID Connect actors/roles. I’m coming from using SAML. In the scenario I’m familiar with, the Service Provider is a web application with protected resources and the Identity Provider server is where users authenticate. With SAML, the typical client is a web browser although SAML also has the ECP profile where a non-browser client (such as a native application) can be used. I understand how all of those pieces work and their various flows.
I’m trying to apply that same understanding to OpenID Connect. My understanding is the OpenID Provider is the same as the Identity Provider. But what about the other pieces? Is the Service Provider the Relying Party? What’s the client then? The OpenID Connect documentation substitutes "Relying Party" with "client" and that’s throwing me off.
To me, coming from SAML, a client is either a web browser or, in the case of ECP, a native or mobile application. So what role is that kind of client in the OpenID Connect world?
Since OpenID Connect is built on OAuth, I've familiarzed myself with it but that hasn't cleared up this SAML to OpenID Connect confusion. Any help would be greatly appreciated. Thanks!
The term "Client" is a generic name that is inherited from OAuth 2.0 for an entity that requests, receives and uses tokens. OpenID Connect builds on top of that but since there's an identity token in play now, the Client is also called Relying Party.
The Relying Party (or Client) is really the same as the SAML Service Provider and the ECP, being the entity that relies on the IDP to provide user identity to it.
The Relying Party (or Client) can be any of a web application, a native application or mobile application.