miniOrange allows you to authenticate your users via API authentication provider into multiple applications.
This way, you can achieve Single Sign-On (SSO) into your applications where the users will need to authenticate themselves via your API Server only once and they can access all the configured applications.
What is API authentication?
Authentication is the method or process by which a user’s identity is verified and recognized. The credentials provided are usually verified against a user store like database, active directory, file etc. API is the interface that allows access to protected resources on request of a user. With remote access to resources it becomes necessary to ensure that only the authorized users have access to the resources. This is where API Authentication comes into play. API Authentication is the process of verifying the identity of the user trying to access resources on the server.
Authentication vs Authorization
Authentication is the process of verifying the identity of the user trying to access a resource and providing proof that the user is who they say they are.
Authorization is the mechanism by which one can determine the access level or user privileges of a resource. In simple terms authorization determines if the user in question has been allowed to access the requested resource. Usually authorization comes after authentication.
In short, authentication identifies who you are and authorization determines what you can do.
HTTP Basic Authentication
HTTP Basic Authentication is the most common and easiest of the authentication methods. Username and password of the user is combined and Base64 encoded. The result is then passed through a special HTTP header known as Authorization. When a user makes a request, the server decodes the Authorization header to verify the username and password. On successful authentication the user is provided access to the requested resource.
HTTP Bearer Authentication
HTTP Bearer Authentication is similar to HTTP Basic Authentication but uses security access token instead of username and password of the user. The access token is usually a random string generated by the server after successful authentication indicating that the user associated with this token has access to the requested resources. This token is sent in the HTTP Header Authorization by the user to access a certain resource. The HTTP Header is read by the server and validated to check if the it’s valid and should have access to the requested resource.
API Key Authentication
API Key Authentication is similar to HTTP Bearer Authentication but provides more flexibility of where the API Key/Token is sent in the request. API Key is usually a long string of alphanumeric characters usually generated at the time of first login or dynamically generated after successful authentication. On subsequent requests the API Key is sent in the request body or header. The server reads the API Key and validates if it’s a valid key and the authorized resources it can access. This method provides the flexibility to the admin to revoke access at any time.
OAuth Authentication
OAuth currently is the best choice for user authentication and authorization amongst all the authentication methods. In this method when users try to access a resource then they are prompted to authenticate themselves or login. After successful authentication a token is generated which can be used to access resources without having the user to authenticate themselves multiple times. OAuth also allows for better security with tighter scope checks and having a time validity for the tokens. As the token is revoked after a while there are less chances of being used by attackers to gain access to resources.
In API key authentication, a key-value pair is sent to the API Server either in Request headers or in request body.
For application specific guides of Wordpress, Moodle, Magento, refer our IDP Setup Guides.
| User Authentication URL | Your API Authentication provider URL. Eg: https://example.com/endpoint/ |
| API Key | The API key value provided by your API Authentication Provider |
In this method, The API key is sent as "Authorization_key" via request header. You can refer to the example below.
| Authentication Parameters | { "username":"##username##", "password":"##password##" } |
| Status | Name of field in the server response that contains the status code |
| Staus Message | Name of the field that gives the description of the status in the response |
In this method, The API key is sent as "api_key" parameter in the POST body as JSON.
To configure your provider to send API key as a field in request body, you can refer below.
| Authentication Parameters | { "api_key":"value", "username":"##username##", "password":"##password##" } |
Put the API key value that you copied in step 1 in place of 'value'. |
| Status | Name of field in the server response that contains the status code |
| Staus Message | Name of the field that gives the description of the status in the response |
| Service Provider Name | Choose appropriate name according to your choice |
| SP Entity ID or Issuer | Your Application Entity ID |
| ACS URL X.509 Certificate (optional) | Your Application Assertion Consumer Service URL |
| NameID Format | Select urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Response Signed | Unchecked |
| Assertion Signed | Checked |
| Encrypted Assertion | Unchecked |
| Group policy | Default |
| Login Method | Password |
| Client Name | Add appropriate Name |
| Redirect URL | Get the Redirect-URL from your OAuth Client |
| Descrption | Add if required |
| Group Name | Default |
| Policy Name | As per your Choice |
| Login Method | Password |
Note: Choose the Authorization Endpoint according to the identity source you configure.
In case you are setting up SSO with Mobile Applications where you can't create an endpoint for Redirect or Callback URL, use below URL.
https://login.xecurify.com/moas/jwt/mobile
You have a choice to set multiple IDPS for Single Application, i.e integrate multiple IDP and users can select IDP accordingly from which they want to authenticate themselves. There are three different ways to authenticate users using IDP.
Note : At once you can select either of them.
Few usecases where customers configure multiple IDPs -
| For Cloud IDP - | https://login.xecurify.com/moas/discovery?customerId=<customer_id> |
| For On-Premise IDP - | https://yourdomain.com/discovery?customerId=<customer_id> |
You can see the screenshot below of the IDP Selection Page with a list of IDPs .
Note: To view the IDP in drop-down list, go to Identity Providers tab > against your configured IDP > Select >Edit , here Enable the Show IdP to Users option.
If you have multiple IDPs and you want a certain set of users to authenticate from one IdP whereas another set of users to authenticate from another IdP, based on their email domains then you can achieve this by using the following steps:- Our domain mapping feature
For your reference , Azure AD and Okta is being used as two different IDPs and WordPress is being used as SP. Follow the guides to set up Okta and WordPress at your end.
If you have multiple IDPs (identity provider) and you want a certain application user to authenticate with one IDP and other application users with another IDP then you can achieve this by our Identity Source Feature.
Need Help? We are right here!
