Hello there!

Need Help? We are right here!

support
miniOrange Email Support
success

Thanks for your inquiry.

If you dont hear from us within 24 hours, please feel free to send a follow up email to info@xecurify.com

OAuth 2.0 Server / OpenID Connect Server

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.

What is OAuth 2.0 Server/OpenID Connect Server?

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.

FEATURES

OAuth Single Sign On (SSO)

We support both OAuth 2.0 and OpenID Connect protocols. They offer a secure way of obtaining the user information from your provider. We use this user information to help you integrate Single Sign-On into your applications.


Supported OAuth Grants

We provide grant type support like Authorization Code Grant, Resource Owner Credentials Grant (Password Grant), Client Credentials Grant, Implicit Grant, Refresh token Grant.


JWT Support

We support JSON Web Token (JWT) authentication. After user logs in, each request includes the JWT allowing the user to access resources that are accessible by that token.


Custom Oauth Provider Support

We can integrate with any custom Oatuh provider including fameous Oauth providers like Google, LinkedIn. We allow our user to choose from multiple algorithms to sign the JWT.Read more


OAuth Single Logout

A user gets logged out from the OAuth Server automatically on logging out with the OAuth Client.


Mobile App Integration / REST APIS’s

Our OAuth / OpenID REST APIs enable integration and single sign-on into your Mobile Applications including iOS, Android, NodeJS, Cordova, Ionic etc.


OAuth Flow

OAuth/openID connect server work flow

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.


OAuth SSO Workflow:

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.

Pre-Integrated Apps




 Oauth 2.0 /OpenID Connect SSO Atlassian application

Atlassian






Setting up OAuth / Open ID Connect in miniOrange

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



API Reference / Documentation



A) Authorization Grant: The application first needs to decide which permissions it is requesting, then sends the user to a browser to get their permission. To initiate this authorization flow, form a URL as below and redirect the end user's browser to the URL:

GET <authorization-endpoint>? response_type=code &client_id=<client_id> &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. To receive authorization code it must have value code. This tells authorization server that application is initiating authorization flow.
client_id The Client ID provided by the OpenID Connect(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.
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.

B) Token Request:

C) Resource Request:

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.

B) Resource Request:

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

B) Resource Request:

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}

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.

B) Revoke a Refresh Token: Since Refresh Tokens never expire, it is essential to be able to revoke them in case they get compromised.


For Further Details Refer:

OAuth
Single Sign On (SSO) using OAuth
OpenID Connect & OAuth 2.0 API Reference


Why Our Customers choose miniOrange Secure Identity Solutions ?


24/7 Support

miniOrange provides 24/7 support for all the Secure Identity Solutions. We ensure high quality support to meet your satisfaction.

Try Now

Affordable Pricing

miniorange provides most affordable Secure Identity Solutions for all type of use cases and offers different packages based on customer's requirement.

Request A Quote


We 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