1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
# Overview
This a description of two authentication and authorization protocols,
and a sketch of acceptance criteria for an implementation of them.
This is very much work in progress.
## Concepts
Some basic concepts in this document:
* **identity** – data about who you are to tell you apart from
everyone else
* **authentication** – proving your identity
* **authorization** – giving you permission to do something
FIXME: These could do with citations.
## The protocols: OAuth and OpenID Connect
[OpenID Connect]: https://openid.net/specs/openid-connect-core-1_0.html
[OAuth]: https://tools.ietf.org/html/rfc6749
The [OAuth][] 2.0 protocol is for authorization, not authentication, and
assumes an already existing way to authenticate users. It's mainly for
giving a service or application permission to do something on your
behalf.
The [OpenID Connect][] 1.0 (OIDC) protocol is for authenticating yourself
to one service or application by using a third party service. This
allows one authentication service (or identity provider) be used for
any number of other services or applications. Further, since the
identity provider can keep a login session open independently of the
other services and applications, this provides a single sign-on
experience.
FIXME: add examples of what each protocol is suited for.
We discuss here only these specific versions of these protocols, and
even then only subsets chosen based mainly from the point of security.
## Entities involved in the protocols
The protocols involves the following entities:
* the **end user**, who is trying to do something; also known as the
resource owner
* the **web browser**, used by the user; might be a mobile or command
line application instead of a browser as such; also know as the user
agent
* the **application**, which the user uses to do things, and as part
of that access resources; also know as the requesting party and the
facade
* the **resource provider**, where the resources are, and which allows
access to them via a web API
* the **identity provider** (IDP), which authenticates the user
FIXME: references for these
# The OAuth 2.0 protocol: client credentials grant
FIXME: give a very high level overview of the protocol, and what
grants are
FIXME: reference some other sources of information
FIXME: explain why only this grant is chosen
See [@rfc8252] for a description of the client credentials grant.
# The OIDC 1.0 protocol: authorization code
FIXME: write this
# References
---
title: "OAuth2 and OpenID Connect: protocols and acceptance criteria"
author: Lars Wirzenius
documentclass: report
bibliography: yuck.bib
bindings:
- yuck.yaml
classes:
- json
...
|
