> For the complete documentation index, see [llms.txt](https://t1t.gitbook.io/t1authentication/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t1t.gitbook.io/t1authentication/overview.md).

# Overview

## Introduction

The T1Authentication service, hosted by Trust1Team is an authentication page which can be used to authenticate users to your application using:

* smart cards, tokens or other hardware identity means
* Smart-ID mobile app

The service is web layer on top of the [Trust1Connector](https://t1t.gitbook.io/t1c-js-guide-v3/) to enable smart token interactions with a local device. The concept enforced by using the Trust1Connector, is to enable a decentralized Identity borker which in solely control of the end-user, the user of your web application. 

Benefits when using the Trust1Authentication service:

* very quick and easy integration (see further and try it out)
* dynamic configurable means (ways for a user to autenticate)
* detailed report for certificate validation
* no need to dive into detailed security implementation in a complex domain
* dynamic branding with customizable authentication flows
* low-cost and maintained externally

## User Interaction Flow

The Relying Party can opt-in for multiple authentication means. An authentication mean is for example:

* 'beid': use Belgian eID smart card for authentication
* 'smart-id: use SmartID mobile application for user authentication

Depending on the allowed authentication means, the user is redirected to the authentication page. The authentication flow is summarized in the image below:

<figure><img src="/files/nBKOy6Rd3hisOleTZ8TB" alt=""><figcaption><p>User Interaction Flow</p></figcaption></figure>

The steps for a user Authentication are:

* Verify phone
* Verify secret (OTP)
* \[Optional] Select Authentication mean
* Identify
* Authentication

After a succesfull user authentication, the user is redirected back to the Relying Party application. When the Relying Party has provided a webhook initially, a HTTP POST request will be provided to the application, prior to the user redirect.&#x20;

The POST request, contains the following information:

* result status
* session context (RP application parameters, correlation ID)
* session tracker information (process step results, tracing information)
* validation report (JSON formatted report of the certificate validation)