▪ Machine-to-Machine Application (M2M)

Machine-to-machine (M2M) applications refer to a communication between two or more machines without the need for human intervention. This type of communication allows machines to exchange information, perform actions, and make decisions based on the data they receive.

M2M applications are used in various industries, such as manufacturing, healthcare, transportation, and energy, to improve efficiency, reduce costs, and automate processes. For example, in the manufacturing industry, M2M applications can be used to monitor and control the production line, detect and predict equipment failures, and optimize energy usage.

M2M communication is typically achieved through the use of sensors, actuators, and other devices that are connected to a network, such as the internet or a local area network. These devices use standardized protocols, such as MQTT or AMQP, to exchange information with each other and with other systems, such as enterprise resource planning (ERP) systems or cloud-based platforms.

Overall, M2M applications are a key component of the Internet of Things (IoT) and play a critical role in the development of smart cities, smart homes, and other connected systems.

1-Settings tab

Under "Settings" tab, you can find information to connect this application in Biopass to the external application on the Internet under OpenID protocol.

OpenID is a protocol for authentication, which enables users to authenticate with multiple websites without having to create and remember a separate username and password for each site. OpenID provides a framework for implementing Single Sign-On (SSO), where a user logs in once and can access multiple websites without having to log in again.

1-1-General information box

On "General information" box you can see:

Application type

Regular Web Application

Application name

The name you choose for your application in Biopass. We recommend you choose the name of your external application for the application in Biopass, so you can easily find it.

Logo URL

The URL indicating the logo is shown in this field. A preview of the logo is shown in a recatngle above this field.

Number of groups

Number of groups that can access this application is written in this field. If number of groups is '0' , then a warning message is shown on top of the box "No user has access to this application. To allow a group of users to log in to this application, add them under "Groups" tab.

Added date

The date and time this application is added to Biopass is shown in this field.

Policy

The policy associated with this application which defines authentication methods based on t he risk of login is noted here. If no policy is associated with this application, a warning message is shown on top of the box "Users cannot log in to this application because there is no policy assigned to it"

If you click on the pen icon on the top right corner of the box, you can edit name, logo and policy of this application.

1-2-"Integration information" box in Machine-to-Machine Application

Use this box to connect this application with the external application you want.

Under this box, you can see "Client ID", "Issuer", "Client secret", information. You have similar fields in the external application that you should fill them with the information here.
For example, if you want to connect "Atlassian" to Biopass, search for "Configure OpenID Connect SSO for Atlassian" on the Internet, and you will find some guides where in Atlassian software you should do the settings.

Here is more information about each field:

"Client ID"

This is the ID of this application in Biopass

"Issuer"

In OAuth, an "Issuer" refers to the entity that issues or generates a security token. Specifically, it is responsible for creating and signing the JSON Web Token (JWT) that contains the user's authorization information.

The Issuer is identified by the "iss" claim within the JWT and is typically a web service or an application that has been authorized to authenticate the user and generate access tokens. The "iss" claim is used to ensure that the token has been issued by a trusted entity and to verify its authenticity.

The Issuer is a crucial part of the OAuth authorization process as it is responsible for ensuring that the user's credentials are valid and that the access token can be trusted. The OAuth client can use the Issuer information to verify the token's authenticity and grant access to protected resources.

"Client authentication" checkbox

Client authentication in OAuth is the process by which the client application (also known as the OAuth client) proves its identity to the authorization server before it is granted access to the protected resources on behalf of the resource owner.

OAuth defines several methods for client authentication, including:

Client ID and Secret: The client provides its client ID and a secret to the authorization server, which is used to authenticate the client. This method is commonly used for web applications.

Public Key: The client presents its public key to the authorization server as proof of identity. This method is commonly used for mobile and desktop applications.

JSON Web Token (JWT): The client presents a JWT to the authorization server as proof of identity. This method is commonly used for APIs.

Client authentication is important for security reasons, as it ensures that only trusted clients are granted access to the protected resources. It also allows the authorization server to enforce access control policies and audit access to the resources.

"Client secret" field & "Rotate secret" button

As stated above, one of the secure methods of "Client authentication" is using Client ID and "Client secret". When "Client authentication" checkbox is ticked, "Client secret" field will appear. In case, you want to change the secret for security reasons, you can use "Rotate secret" button. Remember after changing the secret you should set it in the external application you want to connect Biopass to.

1-3-Grant type

📘

Grant type

In OAuth, a grant type is a type of authorization flow that is used to obtain an access token from the authorization server. The grant type defines how the application requests authorization from the resource owner (the user) and how the authorization server issues the access token to the application.

There are several grant types in OAuth, each with its own characteristics and use cases. Here are some of the most common grant types:

Authorization Code Grant: This is the most commonly used grant type in OAuth. It involves the user being redirected to the authorization server's login page, where they enter their credentials. If the user is authorized, the authorization server returns an authorization code to the application, which is then exchanged for an access token.

Implicit Grant: This grant type is similar to the Authorization Code Grant, but it skips the step where the application exchanges the authorization code for an access token. Instead, the access token is included in the initial authorization response.

Resource Owner Password Credentials Grant: This grant type allows the application to directly authenticate the user's credentials with the authorization server, and then receive an access token in response.

Client Credentials Grant: This grant type is used when the application needs to access its own resources, rather than the resources of a user. The application authenticates with the authorization server using its own credentials, and then receives an access token.

Refresh Token Grant: This grant type is used to obtain a new access token when the current access token has expired. The application sends a request to the authorization server using the refresh token, and if the refresh token is still valid, the authorization server issues a new access token.

Overall, the grant type is a key part of the OAuth flow and determines how the application obtains authorization to access the user's resources on the resource server. It's important for application developers to understand the different grant types and choose the appropriate one for their use case.

1-4-Scopes

📘

Scopes in OpenID protocol

In OAuth, scope is a parameter that is used to define the level of access that a client application has to a user's resources. The scope parameter is included in the authorization request sent by the client application to the authorization server.

The scope parameter is a space-separated list of strings that defines the permissions that the client application is requesting. For example, a client application might request permission to read a user's email, view their profile information, or post on their behalf.

The authorization server is responsible for determining whether to grant the requested scope based on the user's consent and the server's policies. If the authorization server grants the requested scope, it returns an access token to the client application, which the client can use to access the user's resources that are covered by the granted scope.

Scopes help to limit the access of client applications to user resources and prevent unauthorized access. They also give users more control over their data by allowing them to choose which permissions to grant to a client application.