<commit_before>---
title: Overview
type: docs
aliases:
- /architecture/
---

# Overview

Single Sign On for services that use Certificate Authority-based authentication.


## Architecture

There are three components which `ssoca` brings together, and each component can be configured with at least one of several backends.

1. **Certificate Authority / Provider** - responsible for signing certificates which `ssoca` has created/reviewed and approved. The certificates it generates will typically be very short-lived (e.g. expire within a minute) and restricted to the user's session (e.g. username, IP address). [Learn more](certauth).
1. **Identity Provider** - responsible for authenticating users and providing authorization details for their session. This may be handled through browser interaction or CLI prompts, but once completed the client will typically retain a medium-lived token (e.g. one day) with their authorization details. [Learn more](authn).
1. **Service Provider** - responsible for accepting certificates signed by a trusted CA as a form of authentication. Once authenticated, the original, authenticating certificate should no longer be needed. [Learn more](service).

The following diagram demonstrates the high-level interactions which occur between the components.<commit_msg>docs: fix authn/identity provider reference<commit_after>---
title: Overview
type: docs
aliases:
- /architecture/
---

# Overview

Single Sign On for services that use Certificate Authority-based authentication.


## Architecture

There are three components which `ssoca` brings together, and each component can be configured with at least one of several backends.

1. **Certificate Authority / Provider** - responsible for signing certificates which `ssoca` has created/reviewed and approved. The certificates it generates will typically be very short-lived (e.g. expire within a minute) and restricted to the user's session (e.g. username, IP address). [Learn more](certauth).
1. **Identity Provider** - responsible for authenticating users and providing authorization details for their session. This may be handled through browser interaction or CLI prompts, but once completed the client will typically retain a medium-lived token (e.g. one day) with their authorization details. [Learn more](auth/authn).
1. **Service Provider** - responsible for accepting certificates signed by a trusted CA as a form of authentication. Once authenticated, the original, authenticating certificate should no longer be needed. [Learn more](service).

The following diagram demonstrates the high-level interactions which occur between the components.
{'fraction_non_alphanumeric': 0.06777735706171904, 'fraction_numerical': 0.002271866717152594, 'mean_word_length': 4.937078651685393, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1969391', 'n_tokens_mistral': 630, 'n_tokens_neox': 569, 'n_words': 335}