OpenID Connect with .NET Core 2.2 providers by Keycloak , Google and Twitter .
Hi everyone, this is Abdulmohsen. Senior Developer.
How to develop and integrated with SSO ( Single- sign -On) , But first why we’re using OIDC SSO,
Think about “IoT”(Internet of Things) and “Microservices” how to manage authentication and authorization as well , you know microservices have independence that mean you need for each service to handle authentication and authorization, this is to much, the best practice using identity management solutions,
Microservices:
Are a software development technique that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservice-based architectures enable continuous delivery and deployment.
Do you know what is Identity Management
The service function: For user and their devices a system delivers personalized, role-based, online, on-demand, multimedia(content) and presence-based services.
Identity Management has three main basic functions:
The pure identity function: Without regard to access or entitlements for identity creation, management, and deletion.
The user access(log-on) function: For example, to log-on to a service or services.
Identity Federation: To authenticate a user without knowing his/her password can be done by a system using federated identity.
Single Sign-On:
Single sign-on (SSO) is a property of access control for multiple related and independent software systems where user login with single ID and password to gain access to a connected system/s without changing usernames or passwords. SSO is typically accomplished on Lightweight Directory Access Protocol(LDAP) and stored LDAP databases on (directory) servers, an SSO can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain. Shared authentication schemes include OAuth, OpenID, OpenID Connect and Facebook Connect. All the authentication schemes which we use need the user to log in their credentials every time they access a site or application, but we don’t need to get confused with SSO, this single sign-on is enough to sign into different applications. By using SSO users can enter their credentials only one time.
Keycloak:
Keycloak is an open source identity and access management solution which mainly aims at applications and services. Users can authenticate with Keycloak rather than individual applications. So, the applications don’t have to deal with login forms, authenticating users and save users information. Once logged-in to Keycloak, users don’t have to login again to access different applications. Same thing is applicable to sign-out. Keycloak offers everything a sophisticated user management tool needs – without having to log on repeatedly with every login and into every system-as well as system security, social logins, support for mobile apps and integration into other solutions. Keycloak have implementations in LDAP and Active Directory as well.
Keycloak With OpenID Connect(OIDC)
Google With OpenID Connect(OIDC)
Twitter with OpenID Connect(OIDC)
we have three steps :
Step 1: Obtaining a request token
To start a sign-in flow, your Twitter app must obtain a request token by sending a signed message to POST oauth/request_token. The only unique parameter in this request is oauth_callback, which must be a URL-encoded version of the URL you wish your user to be redirected to when they complete step 2. The remaining parameters are added by the OAuth signing process.
Step 2: Redirecting the user
The next step is to direct the user to Twitter so that they may complete the appropriate flow, as described in Browser sign-in flow below. Direct the user to GET oauth/authenticate, and the request token obtained in step 1 should be passed as the oauth_token parameter. The most seamless way for a website to implement this would be to issue an HTTP 302 redirect as the response to the original “sign in” request. Mobile and desktop apps should open a new browser window or direct to the URL via an embedded web view.
Step 3: Converting the request token to an access token
To render the request token into a usable access token, your application must make a request to the POST oauth/access_token endpoint, containing the oauth_verifier value obtained in step 2. The request token is also passed in the oauth_token portion of the header, but this will have been added by the signing process.
Now I think you know what I’m talking about,
Talking is cheap Show me the code CC:(Abdullh Al-Otaibi) ,
let’s do it .
Please visit my account on GitHub to get my code to try this solution
