OAuth Server/OpenID Connect Server (OAuth 2.0 Server) also known as Authorization Server, It is the modern standard for securing access to APIs & implements network protocol flows which allow a client (OAuth Client) to act on behalf of a user.
OAuth Server allows clients to verify the identity of end-users based on the authentication performed by an Authorization Server and also to obtain basic profile information about the end-users in an interoperable and REST-like manner.
OAuth 2.0 Server is used to set up any Application as Identity Server to allow users to Single Sign-On / Login into their client site/application with login using OAuth / OpenID Connect protocol flows.
The primary goal of this OAuth 2.0 server/Oauth Provider is to allow users to interact with multiple apps without requiring them to store sensitive credentials. You can easily configure an OAuth 2.0/OpenID Connect server to protect your API with access tokens, or allow clients to request new access tokens and refresh them.
In this scenario, you can achieve Single Sign On (SSO) into your web application using miniOrange IdP with OAuth / OpenID Connect protocol.
Your web application will act as a OAuth client. In case you do not have an OAuth 2.0 authentication support in your web application, you can use our available OAuth plugins.
1. An unknown user tries to access the resources.
2. Web application sends an authorization request to OAuth Provider / OpenID Connect Server.
3. An OAuth Provider / OpenID Connect Server prompts user to login and authorizes the application.
4. User is redirected to the login page where the user logs in.
5. An OAuth Server / OpenID Connect Provider authenticates the user and sends the authorization code to miniOrange web application.
6. Web application sends its own client_id, client_secret with the authorization code that has received from OAuth Provider / OPenID Connect Server.
7. An OAuth / OpenID Connect Server authenticates the request and sends the Access token to miniOrange OAuth Client.
8. Your web application uses the access token to access resources on the resource server.
9. Using access token, id token and user info miniOrange allows user to access protected features.
10. Now, the user authenticated and logged in. Thus, the application gives access to the resources.
Before your application can use miniOrange Oauth 2.0/OpenID Connect authentication system for user login, you must set up an application in miniOrange administrator console to obtain Oauth 2.0/OpenID Connect credentials, set a redirect URI, and add an application name. You need Oauth 2.0/OpenID Connect credentials, including a client ID and client secret, to authenticate users and gain access to miniOrange APIs. To get the credentials, do the following:
Step 1. Create an Application in miniOrange Administrator Console
So now once you have created the application for OpenID Connect. You need to create a policy for the same to let user authenticate with our various strong authentication methods.
Step 2. Create a policy
Step 3: Integration with client Application
A) Authorization Request: The application first needs to decide which permissions it is requesting, then send the user to a browser to get their permission. To initiate this implicit flow, form a URL as below and redirect the end user's browser to the URL:
GET <authorization-endpoint>?
response_type=<token>
&client_id= <client_id_goes_here>
&redirect_uri= <callback_url>
&scope= <openid>
&state= <security_token>
Field | Description |
---|---|
<authorization-endpoint> | Authorization Endpoint that you get from the Step 1 above. |
response_type | The type of response you are expecting. This tells authorization server that application is initiating implicit flow. Note the difference from the Authorization Code flow where this value is set to code. |
client_id | The Client ID provided by the OAuth provider. |
redirect_uri | Callback Url to which user will be redirected once they allow or disallow the access to your app. |
scope | One or more space separated strings which indicates the permission your application requesting. |
state | The application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. |
https://callback-url?
#id_token=<id_token>
&token_type=Bearer
&expires_in=3600
&state=<security_code>
Field | Description |
---|---|
id_token | The ID Token is a security token that contains Claims about the authentication of an End-User by an Authorization Server when using a Client, and potentially other requested claims. |
access_token | access token for the Userinfo endpoint. |
token_type | OAuth 2.0 token type value. The value must be Bearer. |
expires_in | The expiry time for the access token. |
scope | One or more space seperated strings which indicates the permission your application requesting. |
B) Resource Request:
GET <userinfo-endpoint>
Request Header
Authorization: Bearer <access_token>
Field | Description |
---|---|
<userinfo-endpoint> | Userinfo endpoint that you get from the Step 1 above. |
access_token | Access token for the Userinfo endpoint. |
Successful Userinfo Response | The UserInfo Claims MUST be returned as the members of a JSON object. |
{
"sub" : "abxc",
"email" : "xyz@example.com",
"email_verified" : true,
"name" : "xyz pqr",
"given_name" : "xyz",
"family_name" : "pqr",
"phone_number" : "+359 (99) 100200305",
"profile" : "https://test.com/xyz",
"https://c2id.com/groups" : [ "audit", "admin" ]
}
The resource owner password (or "password") grant type is mostly used in cases where the app is highly trusted. In this configuration, the user provides their resource server credentials (username/password) to the client app, which sends them in an access token request.
A) Token Request: The Password grant involves only one step: the application presents a traditional username and password login form to collect the user’s credentials and makes a POST request to the server to exchange the password for an access token. The POST request that the application makes looks like the example below:
POST <token-endpoint>
Request Header
Content-type: application/x-www-form-urlencoded
Request Body
grant_type=password
&username=exampleuser
&password=12345678
&client_id=xxxxxxxxxx
Field | Description |
---|---|
<token-endpoint> | Token endpoint that you get from the Step 1 above |
grant_type | This tells the server we’re using the Password grant type |
username | The user’s username that they entered in the application |
password | The user’s password that they entered in the application |
client_id | The public identifier of the application that the developer obtained during registration |
https://callback-url?
#access_token=<access_token>
&token_type=Bearer
&expires_in=3600
&id_token=<id_token>
Field | Description |
---|---|
access_token | access token for the Userinfo endpoint. |
token_type | OAuth 2.0 token type value. The value must be Bearer. |
expires_in | The expiry time for the access token. |
id_token | The ID Token is a security token that contains Claims about the authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims |
B) Resource Request:
GET <userinfo-endpoint>
Request Header
Authorization: Bearer <access_token>
Field | Description |
---|---|
<userinfo-endpoint> | Userinfo endpoint that you get from the Step 1 above. |
access_token | access token for the Userinfo endpoint. |
Successful Userinfo Response | The UserInfo Claims MUST be returned as the members of a JSON object. |
{
"sub" : "abxc",
"email" : "xyz@example.com",
"email_verified" : true,
"name" : "xyz pqr",
"given_name" : "xyz",
"family_name" : "pqr",
"phone_number" : "+359 (99) 100200305",
"profile" : "https://test.com/xyz",
"https://c2id.com/groups" : [ "audit", "admin" ]
}
Client Credentials grant can be used for machine to machine authentication. In this grant a specific user is not authorized but rather the credentials are verified and a generic access_token is returned.
A) Token Request: To receive an id token, the client POSTs an API call with the values for Client ID and Client secret obtained from a registered developer app as follow:
POST <token-endpoint>
Request Header
Content-Type: application/x-www-form-urlencoded
Request Body
grant_type=client_credentials&
client_id={client_id}&
client_secret={clientSecret}
Field | Description |
---|---|
grant_type | This tells the server we’re using the client credentials grant type. |
client_id | The public identifier of the application that the developer obtained during registration. |
client_secret | The client secret provided by the OIDC provider. |
redirect_uri | Callback Url to which user will be redirected once they allow or disallow the access to your app. |
scope | One or more space separated strings which indicates the permission your application requesting. |
{
"access_token": ,
"expires_in": 600,
"token_type": "Bearer"
}
Field | Description |
---|---|
access_token | access token for the Userinfo endpoint. |
token_type | OAuth 2.0 token type value. The value must be Bearer. |
A Refresh Token allows the application to issue a new Access Token or ID Token without having to re-authenticate the user. This will work as long as the Refresh Token has not been revoked.
A)Refresh Token Request: The response of token request should contain access token ans refresh token.
POST <token-endpoint>
Request Header
Content-Type: application/x-www-form-urlencoded
Request Body
grant_type=refresh_token&
client_id={client_id}&
client_secret={client_secret}&
refresh_token={refresh_token}
Field | Description |
---|---|
<token-endpoint> | Token endpoint that you get from the Step 1 above. |
grant_type | This tells the server we’re using the refresh token grant type. |
client_id | The public identifier of the application that the developer obtained during registration. |
client_secret | The client secret provided by the OAuth provider. |
refresh_token | The refresh token to use. |
{
"access_token": "eyJ...MoQ",
"expires_in": 86400,
"scope": {scope},
"id_token": "eyJ...0NE",
"token_type": "Bearer"
}
B) Revoke a Refresh Token: Since Refresh Tokens never expire, it is essential to be able to revoke them in case they get compromised.
POST <revoke-endpoint>
Request Header
Content-Type: application/x-www-form-urlencoded
Request Body
client_id={client_id}&
client_secret={client_secret}&
refresh_token={refresh_token}
Field | Description |
---|---|
<revoke-endpoint> | Revoke endpoint that you get from the Step 1 above. |
client_id | The public identifier of the application that the developer obtained during registration. |
client_secret | The client secret provided by the OAuth provider. |
refresh_token | The refresh token to use. |
miniOrange provides 24/7 support for all the Secure Identity Solutions. We ensure high quality support to meet your satisfaction.
Try Nowminiorange provides most affordable Secure Identity Solutions for all type of use cases and offers different packages based on customer's requirement.
Request A QuoteWe offer Secure Identity Solutions for Single Sign-On, Two Factor Authentication, Adaptive MFA, Provisioning, and much more. Please contact us at -
+1 978 658 9387 (US) , +91 77966 99612 (India) | info@xecurify.com