# Authenticity

**In short:** Authenticity is the degree to which you can prove that a user, device, or resource is the one it claims to be. ISO/IEC 25010 lists it as a security sub-characteristic.

## Explanation

ISO/IEC 25010 is a standard quality model (see ISO/IEC 25010 Product Quality Model). It places authenticity under security. It defines authenticity as the degree to which the identity of a subject or resource can be proved to be the one claimed.

**Where it sits in security.** Security means defending against attack patterns by malicious actors and protecting information and data. Authenticity has several siblings under security:

- Confidentiality: data are accessible only to those authorized. See Confidentiality.
- Non-repudiation: actions or events can be proven to have happened, so nobody can deny them later. See Nonrepudiation.
- Accountability: the actions of an entity can be traced uniquely to that entity. See Accountability.
- Resistance: the system keeps operating while under attack. See Resistance.

**Authentication versus authorization.** These words sound alike but differ.

- Authentication is the process of proving you are who you say you are. It verifies the identity of a person or device.
- Authorization comes after that. It gives an authenticated party permission. It says what data the party may access and what it may do with that data.

Authenticity is the quality you want as the outcome: an identity that can be proved.

**Mechanisms.** Multifactor authentication adds another authentication factor to an account. It is often used to protect against brute force attacks.

**Federated identity.** An application can delegate authentication to a central identity provider. Users then sign in once and are signed in automatically to every app that shares the same directory. This is called single sign-on. Apps no longer need to administer their own credentials.

**OpenID Connect.** OpenID Connect is an identity layer on top of OAuth 2.0. It lets a client verify the identity of the end user, based on authentication done by an authorization server.

**2023 revision.** The 2023 revision added resistance as a security sub-characteristic. The source describing the changes mentions no change to authenticity.

## Example

A company runs an online ordering system and several internal tools. Instead of each tool keeping its own passwords, all tools send sign-in to one central identity provider. Staff sign in once, and a second factor is required. The ordering system then checks what each signed-in person may do. The architecture document states which identities must be provable (staff and partner systems) and names the provider that proves them.

## Trade-offs

The facts here do not quantify costs. Some trade-offs follow from the mechanisms. Multifactor authentication adds a step to every sign-in, which asks more of users. Delegating authentication to a central identity provider removes per-app credential administration. It also makes that provider an important dependency. Weigh these choices against other qualities (see Quality Attribute Trade-off).

Authentication proves the claimed identity; authorization then decides what that identity may do.

```mermaid
flowchart LR
  A[User or device claims an identity] --> B[Authentication: verify the claim]
  B -->|proved| C[Authorization: decide what is allowed]
  B -->|not proved| D[Access refused]
  C --> E[Access to data and actions]
```

## Checks

- The document states which subjects and resources must have a provable identity.
- Authentication and authorization are described as separate steps.
- The document says whether multifactor authentication is used and why.
- If authentication is delegated to a central identity provider, the document names it and the single sign-on approach.

## Related

- [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md)
- [Confidentiality](https://arc.fuet.ch/concepts/quality-attributes/confidentiality.md)
- [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md)
- [Accountability](https://arc.fuet.ch/concepts/quality-attributes/accountability.md)
- [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md)
- [Integrity](https://arc.fuet.ch/concepts/quality-attributes/integrity.md)
- [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md)

## Sources

- [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?start=6) — iso25000.com, accessed 2026-11-09
- [Update on ISO 25010, version 2023 | arc42 Quality Model](https://quality.arc42.org/articles/iso-25010-update-2023) — quality.arc42.org, accessed 2026-11-08
- [Authentication vs. authorization - Microsoft identity platform | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/authentication-vs-authorization) — learn.microsoft.com, accessed 2026-11-09
- [Final: OpenID Connect Core 1.0 incorporating errata set 2](https://openid.net/specs/openid-connect-core-1_0.html) — openid.net, accessed 2026-11-09