▪ Single Page Application (SPA)

A Single Page Application (SPA) is a type of web application that interacts with the user dynamically by re-rendering the current page instead of loading entire new pages from a server. In an SPA, the majority of the code is executed client-side in the browser using JavaScript, while the backend provides a simple API to serve the data needed by the application.

This architecture provides a seamless experience to the user, as the web page does not need to reload for each user action. Instead, the application updates the necessary components dynamically, providing a fast and fluid user experience.

Some of the popular front-end frameworks used for building SPAs include React, Angular, and Vue.js. SPAs are used for a wide range of web applications, from simple to-do lists to complex e-commerce sites.

You can use fast secure Biopass passwordless authentication for those applications. You should first create a corresponding application in Biopass admin panel. Then connect the application in Biopass with that application as explained in Step 4.


Remember that when you connect your application with Biopass, Biopass will be your OpenID Connect identity provider . After configuring, a button will appear on the sign-in page of your application, and clicking on it your user is directed to Biopass Universal Login, they enter their Biopass username and guided to authentiacte.

Single Sign On with Biopass

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

Single Page 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 Single Page 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-"Allowed callback URLs" box in Single Page Application

This box should contain all "Allowed callback URLs" set for applications. When Biopass verifies user, it should redirect the user to the requested application URL. This is done only when the redirct URL is in the list of "Allowed callback URLs".

📘

Allowed Callback URL

An "Allowed Callback URL" is a setting used in web applications that implement OAuth authentication, which allows users to grant third-party applications access to their accounts on a given service without providing their login credentials.

When a user grants access to a third-party application, the OAuth protocol will redirect the user to the application's "callback URL" after the user has authenticated with the service. The "Allowed Callback URL" setting specifies which URLs the service should accept as valid callback URLs for a given application.

This setting is important for security reasons, as it helps to prevent unauthorized access to user accounts. By limiting the allowed callback URLs to only those that belong to trusted applications, the service can ensure that users are only granting access to their accounts to legitimate and trusted third-party applications.

In short, the "Allowed Callback URL" is a configuration option that helps ensure that the OAuth authentication process is secure and that users can trust the third-party applications they grant access to.

1-4-Sign-out URLs (Optional)

📘

Sign-out URLs

In OAuth, a sign-out URL is a URL that is used to log a user out of an application or service that they have authenticated with using OAuth. When a user logs into an application using OAuth, they grant the application access to their account on the service provider's platform.

When a user logs out of the application, the access token that was generated during the OAuth authentication process must be revoked so that the application can no longer access the user's account. This is where the sign-out URL comes in - it is the URL that the user is directed to when they log out of the application, and it is responsible for revoking the access token.

The sign-out URL can be a URL provided by the service provider, or it can be a custom URL created by the application developer. When a user logs out, the application makes a request to the sign-out URL to revoke the access token. Once the access token is revoked, the user is logged out and the application can no longer access their account.

It's worth noting that not all service providers require the use of a sign-out URL, and some may handle access token revocation in a different way. However, for applications that use OAuth and require access to sensitive user data, using a sign-out URL is a good practice to ensure that user data is protected.

1-5-Initiate login URI (Optional)

📘

Initiate login URI

In OAuth, an Initiate Login URI (also known as the authorization endpoint) is the URL where a user is redirected to initiate the OAuth flow for a particular application or service. The initiate login URI is the first step in the OAuth authorization process and is where the user is prompted to grant permission to the application to access their account on the service provider's platform.

When a user clicks the "Login with [Service Provider]" button on an OAuth-enabled application, the application will redirect the user's browser to the initiate login URI for that particular service provider. Once the user reaches the initiate login URI, they will be prompted to enter their login credentials for the service provider. After the user has successfully authenticated, they will be presented with a consent screen that explains what permissions the application is requesting and gives the user the option to grant or deny access to their account.

If the user grants access, the service provider will generate an authorization code, which the application can exchange for an access token that allows it to access the user's account. This exchange typically happens at the token endpoint, which is a different URI from the initiate login URI.

Overall, the initiate login URI is a critical part of the OAuth flow, as it's where the user's authentication and authorization are initiated. Without the initiate login URI, the OAuth flow could not be initiated, and the application would not be able to access the user's account on the service provider's platform.

1-6-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-7-Scope

In this box, admin can limit the access of external applications to user resources in Biopass and prevent unauthorized access.
Admin can give external application access to user information on different levels:

"OpenID"

The "openid" scope is a required scope in the OpenID protocol, and it is used to indicate that the user is authenticating themselves using the OpenID protocol.

When a relying party sends an OpenID authentication request to an OpenID provider, the request must include the "openid" scope. This tells the OpenID provider that the request is an OpenID authentication request, and that the provider should use the OpenID protocol to authenticate the user.

If the user successfully authenticates with the OpenID provider, the provider will include an "openid" scope in the response, along with any other requested scopes (such as "profile" or "email"). The relying party can then use the information provided in the response to authorize the user's access to the site or application.

In other words, the "openid" scope is essentially the "key" that unlocks the OpenID authentication process. Without this scope, the OpenID provider would not know that the request is an OpenID authentication request, and the authentication process would not work correctly.

"Email"

The "email" scope in OpenID is another predefined scope that allows an OpenID provider to share a user's email address with a relying party (i.e., the website or application that the user is trying to access).

When a relying party requests the email scope in an OpenID authentication request, the OpenID provider will display a consent screen to the user, asking them to authorize the sharing of their email address. If the user grants consent, the OpenID provider will include the email address in the OpenID authentication response, which the relying party can then use to communicate with the user or to verify their identity.

The email scope can be useful for applications that require a user's email address for account verification, communication, or other purposes. However, it's important to note that not all OpenID providers will share a user's email address by default, and some providers may require additional permissions or settings to be configured before email addresses can be shared.

It's also worth noting that the email scope is just one of many possible scopes that can be used in OpenID authentication requests, and the specific set of scopes that are requested will depend on the needs of the relying party and the OpenID provider. Additionally, users can choose to restrict or limit the information that is shared with relying parties by adjusting their privacy settings with their OpenID provider.

"Profile"

The "profile" scope in OpenID is one of the predefined scopes that allows an OpenID provider to share a user's profile information with a relying party (i.e., the website or application that the user is trying to access).

The profile scope is typically used to request access to a user's basic profile information, such as their name, nickname, picture, and preferred language. The specific profile information that is shared may vary depending on the OpenID provider and the user's privacy settings.

When a relying party requests the profile scope, the OpenID provider will typically display a consent screen to the user, asking them to authorize the sharing of their profile information. If the user grants consent, the OpenID provider will include the requested profile information in the OpenID authentication response, which the relying party can then use to personalize the user's experience.

It's important to note that the profile scope is just one of many possible scopes that can be used in OpenID authentication requests, and the specific set of scopes that are requested will depend on the needs of the relying party and the OpenID provider. Additionally, users can choose to restrict or limit the information that is shared with relying parties by adjusting their privacy settings with their OpenID provider.

"Phone"

The "phone" scope in OpenID is a predefined scope that allows an OpenID provider to share a user's phone number with a relying party (i.e., the website or application that the user is trying to access).

When a relying party requests the phone scope in an OpenID authentication request, the OpenID provider will display a consent screen to the user, asking them to authorize the sharing of their phone number. If the user grants consent, the OpenID provider will include the phone number in the OpenID authentication response, which the relying party can then use to communicate with the user or to verify their identity.

The phone scope can be useful for applications that require a user's phone number for account verification, two-factor authentication, or other purposes. However, not all OpenID providers will share a user's phone number by default, and some providers may require additional permissions or settings to be configured before phone numbers can be shared.

It's important to note that the phone scope is just one of many possible scopes that can be used in OpenID authentication requests, and the specific set of scopes that are requested will depend on the needs of the relying party and the OpenID provider. Additionally, users can choose to restrict or limit the information that is shared with relying parties by adjusting their privacy settings with their OpenID provider.

📘

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.

2-Groups tab

Under this tab, you can see the groups whose users can access this application in cards. On each card, some information such as number of users in the group, the date they are added to access the application exists. To add a group to your application, use "+ Add group" button. A search bar appears that show groups in admin panel which are not added to the application. If you click on any of them, the group is added, and users in the group can authenticate and log in to the application. To remove the group, click on the "x' on the top right corner of the card.