OpenID Connect Introduction

-


What is OpenID Connect??

OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol, which allows clients to verify the identity of an end user based on the authentication performed by an authorization server or identity provider (IdP), as well as to obtain basic profile information about the end user in an interoperable and REST-like manner. OpenID Connect specifies a RESTful HTTP API, using JSON as a data format. 
OpenID Connect is an increasingly common authentication protocol: when an app prompts you to authenticate using your Facebook or Google+ credentials, the app is probably using OpenID Connect.OpenID Connect allows a range of clients, including web-based, mobile, and JavaScript clients, to request and receive information about authenticating sessions and end-users. OIDC main purpose is to authenticate user one login and allow access to multiple services which is also known as SSO (Single Sign-On).
OneLogin provides a custom connector option that makes it easy to configure your OpenID Connect-enabled app to use OneLogin as the Identity Provider (IdP) in an OpenID Connect flow. 

Authentication flow in OpenID Connect



The following diagram depicts the initial authentication flow ...

  1. An unauthenticated user requests a protected resource from the BPM server (here: the Process Portal landing page)
    Because this was an unauthenticated request, the server redirects the browser to the configured OpenID Connect Offering Party for authentication.                                                                                    
  2. The browser interacts with the OIDC OP. It basically asks for an authorization code that it can provide to the OIDC Relying Party (RP), that is: to BPM.                                                                       
  3. Assuming this is an initial request to the OIDC OP, the user needs to authenticate first. The exact authentication mechanism is up to the OIDC Offering Party. For example, it might require a smart card in an external device, a 6 digit number that is displayed on an authenticator device or app, or simply a userID and password. In the simplest case, a WebSphere Liberty Profile server (acting as OIDC OP) redirects the browser to fetch a regular login page.
    If the user was already authenticated by the OIDC OP server (e.g. because he had accessed another OIDC RP system earlier today) this login step would be omitted.                                                 
  4. Upon login form submission, the OIDC /authorize endpoint is triggered and provides an authorization code to the end user's browser.                                                                                            
  5. The browser now POSTs this code to the OIDC RP (BPM).                                                                     
  6. An authorization code is just an opaque token that does not mean anything to the OIDC RP. The built-in OIDC support in WebSphere thus calls the configured OIDC OP to exchange the authorization code for a number of tokens: access_token, refresh_token and id_token.                                                                                              
  7. The id_token already contains enough information to log the user in (establish a JAAS subject for a user). If the application on top of WAS wanted to, it could use the access_token to call the OIDC OP's /userinfo endpoint to obtain additional information. BPM does not do that.                                                                                                               
  8. As the user is now logged in, the request for /ProcessPortal can be processed and the Portal landing page is returned.

Access Token

The ID Token is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth, typically used for UI display. ID Tokens conforms to an industry standard (IETF RFC 7519) and contain three parts: a header, a body, and a signature.

ID Token

A client receives the identity of the user in encoded JSON format. This JWT is called ID token. JWTs are portable and support a wide variety of signature algorithms. It makes easier to ID Token verification.
ID Token is a concept of a identity card in JSON format.  This token is usually signed by the OIDC provider. So it can be verified and make sure the ID Token is not altered. ID Token contains the Identity of the user. It may usually contain the following details
  • Asserts the identity of the user, called subject in OpenID (sub). [email, first name, lastname etc.]
  • Specifies the issuing authority (iss).
  • Is generated for a particular audience, i.e. client (aud).
  • May contain a nonce (nonce).
  • May specify when (auth_time) and how, in terms of strength (acr), the user was authenticated.
  • Has an issue (iat) and expiration time (exp).
  • May include additional requested details about the subject, such as name and email address.
  • Is digitally signed, so it can be verified by the intended recipients.
  • May optionally be encrypted for confidentiality.
This ID token usually comes with  JSON and signature are encoded into a base 64 URL-safe string. You can decode the id token from the client side.

There are some endpoints in OpenID Connect :

Server discovery Endpoint Discover the OAuth 2.0 / OpenID Connect endpoints, capabilities supported cryptographic algorithms and features.
Server JWK set Endpoint Retrieve the public server JSON Web Key (JWK) required to verify the authenticity of issued ID and access tokens.
UserInfo endpointThe UserInfo endpoint returns previously consented user profile information to the client. A valid access token is required for that.
Authorization Endpoint The client sends the end user's browser to this endpoint to request their authentication and consent. This endpoint is used in the code and implicit OAuth 2.0 flows which require end-user interaction.
Token Endpoint Post an OAuth 2.0 grant (code, refresh token, resource owner password credentials, client credentials) to obtain an ID and/or access token.
Token introspection Endpoint Validate an access token and retrieve its underlying authorization (for resource servers).
Token revocation Endpoint Revoke an obtained access or refresh token.
In this document discussed about what is OpenID Connect and overview of the protocol.


Comments

Post a Comment

Popular posts from this blog

How to hack windows 2000 using nessus.....

-
Image
What is nessus? Nessus  is a propriety vulnerability scanner developed by tenable network. It is free of charge for personal use in a non-enterprise environment. We use kali Os to hacking windows server, to testing vulnerabilities . ·          In Linux we have to search both Os are in the same network. And search the ip address of each systems.              ·          To windows :Open the terminal and type “ipconfig”                                     ·          To Linux : Open terminal and type      “ifconfig”                                   ·          Ten now we have both ip addresses. Using ping command can check the connection between        each        other.                                     Ex: ping 192.168.55.99 ·          Then both are connected we can start the nessus and can find the vulnerabilities. ·                                        Using “service ness
Read more

Crypt-analysis

-
Image
                                The goal of cryptanalysis is to find some weakness or insecurity in a cryptographic scheme, thus permitting its subversion or evasion.   It is a common misconception that every encryption method can be broken.   In connection with his WWII work at  Bell Labs proved that the  one-time pad  cipher is unbreakable, provided the key material is truly  random , never reused, kept secret from all possible attackers, and of equal or greater length than the message.    Most ciphers, apart from the one-time pad, can be broken with enough computational effort by  brute force attack , but the amount of effort needed may be  exponentially  dependent on the key size, as compared to the effort needed to make use of the cipher. In such cases, effective security could be achieved if it is proven that the effort required is beyond the ability of any adversary. This means it must be shown that no efficient method can be found to break the cipher.  
Read more