<commit_before>---
id: oauth2
title: OAuth 2.0 and OpenID Connect
sidebar_label: OAuth 2.0
---

This section describes on a high level what OAuth 2.0 and OpenID Connect 1.0 are
for and how they work.

### OAuth 2.0

[The OAuth 2.0 authorization framework](https://tools.ietf.org/html/rfc6749) is
specified in [IETF RFC 6749](https://tools.ietf.org/html/rfc6749). OAuth 2.0
enables a third-party application to obtain limited access to resources on an
HTTP server on behalf of the owner of those resources.

Why is this important? Without OAuth 2.0, a resource owner who wants to share
resources in their account with a third party would have to share their
credentials with that third party. As an example, let's say you (a resource
owner) have some photos (resources) stored on a social network (the resource
server). Now you want to print them using a third-party printing service. Before
OAuth 2.0 existed, you would have to enter your social network password into the
printing service so that it can access and print your photos. Sharing secret
passwords with third parties is obviously very problematic.

OAuth addresses this problem by introducing:

- the distinction between resource ownership and resource access for clients
- the ability to define fine-grained access privileges (called OAuth scopes)
  instead of full account access for third parties
- an authorization layer and workflow that allows resource owners to grant
  particular clients particular types of access to particular resources.

With OAuth, clients can request access to resources on a server, and the owner
of these resources can grant the requested access together with dedicated
credentials. In our example, you could grant the printing service read-only
access to your photos (only your photos, not your friend list) on the social
network. These credentials come in the form of an access token -- a string
denoting a specific scope, lifetime, and other access attributes. The client
(printing service) can use this access token to request the protected resources
(your photos) from the resource server (the social network).

### What is OpenID Connect 1.0?

OAuth 2.0 is a complex protocol for authorizing access to resources. If all you
need is authentication, OpenID Connect 1.0 enables clients to verify the
identity of the end user based on the authentication performed by an
Authorization Server and obtain basic profile information in an interoperable
and REST-like manner.

OpenID Connect allows clients of all types, including web and mobile, to receive
information about authenticated sessions and end users. The specification is
extensible, allowing participants to add encryption of identity data, discovery
of OpenID Providers, and session management as needed.

There are different work flows for OpenID Connect 1.0. We recommend checking out
the OpenID Connect sandbox at [openidconnect.net](https://openidconnect.net/).

A more detailed introduction of both OAuth 2.0 and OpenID Connect is available
in the following video:

<iframe width="560" height="315" src="https://www.youtube.com/embed/996OiexHze0" frameborder="0" allowfullscreen></iframe>

More details about the various OAuth2 flows can be found in these articles:

- [DigitalOcean: An Introduction to OAuth 2](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2)
- [<NAME>: OAuth2 Simplified](https://aaronparecki.com/2012/07/29/2/oauth2-simplified)
- [Zapier: Chapter 5: Authentication, Part 2](https://zapier.com/learn/apis/chapter-5-authentication-part-2/)

1. ORY Hydra does not manage user accounts. Your application does that. Hydra
   exposes an OAuth 2.0 and OpenID Connect endpoint for the user accounts of
   your application.
2. OAuth Scopes are not access permissions to resources. They entitle an
   external application to act in the name of a user on a particular type of
   resource.

### OAuth 2.0 Scope != Permission

:::info The OAuth2 Scope reflects a permission the user gave to the OAuth2
Application, not a permission the system (e.g. API) gave to that OAuth2
application. Also, the OAuth2 Scope can not be changed without revoking the
token. :::

A second important concept is the OAuth 2.0 Scope. Many people confuse OAuth 2.0
Scope with internal Access Control like for example Role Based Access Control
(RBAC) or Access Control Lists (ACL). Both concepts cover different aspects of
access control.

Internal access control (RBAC, ACL, etc) decides what a user can do in your
system. An administrator might be allowed to modify everything. A regular user
might only be allowed to read their own messages.

OAuth 2.0 Scopes, on the other hand, describe what a user allowed an external
application (OAuth 2.0 client) to do on his/her behalf. For example, an access
token might grant the external application to see a user's pictures, but not
upload new pictures on his/her behalf (which we assume a user could do herself).

In an extreme case, the user could lie and grant an external application OAuth
scopes that he himself doesn't have permission to ("read all classified
documents"). The OAuth Access Token with those scopes wouldn't help the external
application read those documents because it can only act in the name of the
user, and that user doesn't have these access privileges.

To recap, ORY Hydra's primary feature is implementing the OAuth 2.0 and OpenID<commit_msg>Update oauth2.md<commit_after>---
id: oauth2
title: OAuth 2.0 and OpenID Connect
sidebar_label: OAuth 2.0
---

This section describes on a high level what OAuth 2.0 and OpenID Connect 1.0 are
for and how they work.

### OAuth 2.0

[The OAuth 2.0 authorization framework](https://tools.ietf.org/html/rfc6749) is
specified in [IETF RFC 6749](https://tools.ietf.org/html/rfc6749). OAuth 2.0
enables a third-party application to obtain limited access to resources on an
HTTP server on behalf of the owner of those resources.

Why is this important? Without OAuth 2.0, a resource owner who wants to share
resources in their account with a third party would have to share their
credentials with that third party. As an example, let's say you (a resource
owner) have some photos (resources) stored on a social network (the resource
server). Now you want to print them using a third-party printing service. Before
OAuth 2.0 existed, you would have to enter your social network password into the
printing service so that it can access and print your photos. Sharing secret
passwords with third parties is obviously very problematic.

OAuth addresses this problem by introducing:

- the distinction between resource ownership and resource access for clients
- the ability to define fine-grained access privileges (called OAuth scopes)
  instead of full account access for third parties
- an authorization layer and workflow that allows resource owners to grant
  particular clients particular types of access to particular resources.

With OAuth, clients can request access to resources on a server, and the owner
of these resources can grant the requested access together with dedicated
credentials. In our example, you could grant the printing service read-only
access to your photos (only your photos, not your friend list) on the social
network. These credentials come in the form of an access token -- a string
denoting a specific scope, lifetime, and other access attributes. The client
(printing service) can use this access token to request the protected resources
(your photos) from the resource server (the social network).

### What is OpenID Connect 1.0?

OAuth 2.0 is a complex protocol for authorizing access to resources. If all you
need is authentication, OpenID Connect 1.0 enables clients to verify the
identity of the end user based on the authentication performed by an
Authorization Server and obtain basic profile information in an interoperable
and REST-like manner.

OpenID Connect allows clients of all types, including web and mobile, to receive
information about authenticated sessions and end users. The specification is
extensible, allowing participants to add encryption of identity data, discovery
of OpenID Providers, and session management as needed.

There are different work flows for OpenID Connect 1.0. We recommend checking out
the OpenID Connect sandbox at [openidconnect.net](https://openidconnect.net/).

A more detailed introduction of both OAuth 2.0 and OpenID Connect is available
in the following video:

<iframe width="560" height="315" src="https://www.youtube.com/embed/996OiexHze0" frameborder="0" allowfullscreen></iframe>

More details about the various OAuth2 flows can be found in these articles:

- [DigitalOcean: An Introduction to OAuth 2](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2)
- [<NAME>: OAuth2 Simplified](https://aaronparecki.com/2012/07/29/2/oauth2-simplified)
- [Zapier: Chapter 5: Authentication, Part 2](https://zapier.com/learn/apis/chapter-5-authentication-part-2/)

1. ORY Hydra does not manage user accounts. Your application does that. Hydra
   exposes an OAuth 2.0 and OpenID Connect endpoint for the user accounts of
   your application.
2. OAuth Scopes are not access permissions to resources. They entitle an
   external application to act in the name of a user on a particular type of
   resource.

### OAuth 2.0 Scope != Permission

:::info The OAuth2 Scope reflects a permission the user gave to the OAuth2
Application, not a permission the system (e.g. API) gave to that OAuth2
application. Also, the OAuth2 Scope can not be changed without revoking the
token.

:::

A second important concept is the OAuth 2.0 Scope. Many people confuse OAuth 2.0
Scope with internal Access Control like for example Role Based Access Control
(RBAC) or Access Control Lists (ACL). Both concepts cover different aspects of
access control.

Internal access control (RBAC, ACL, etc) decides what a user can do in your
system. An administrator might be allowed to modify everything. A regular user
might only be allowed to read their own messages.

OAuth 2.0 Scopes, on the other hand, describe what a user allowed an external
application (OAuth 2.0 client) to do on his/her behalf. For example, an access
token might grant the external application to see a user's pictures, but not
upload new pictures on his/her behalf (which we assume a user could do herself).

In an extreme case, the user could lie and grant an external application OAuth
scopes that he himself doesn't have permission to ("read all classified
documents"). The OAuth Access Token with those scopes wouldn't help the external
application read those documents because it can only act in the name of the
user, and that user doesn't have these access privileges.

To recap, ORY Hydra's primary feature is implementing the OAuth 2.0 and OpenID
{'fraction_non_alphanumeric': 0.052577893175074185, 'fraction_numerical': 0.01678412462908012, 'mean_word_length': 4.536447638603696, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 14, 'lorem ipsum': 0, 'www.': 4, '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': '7047502', 'n_tokens_mistral': 2862, 'n_tokens_neox': 2701, 'n_words': 1568}