summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIvan Dolgov <ivan@dolgov.fi>2021-02-22 14:18:37 +0000
committerIvan Dolgov <ivan@dolgov.fi>2021-02-22 14:18:37 +0000
commit8a9c0e21a27e9f074f3073610c67894155f50a77 (patch)
tree80fc5163e53995c5e22a21bd4dadea220ab62671
parent81fe323d603d9dcb9e1bbf1d2abe1742949c5f06 (diff)
parent9ad03d71d7e939518174ec3bd44f56f10061d049 (diff)
downloadyuck-8a9c0e21a27e9f074f3073610c67894155f50a77.tar.gz
Merge branch 'refs' into 'main'
refactor: use hyperlinks instead of BibTeX for references See merge request larswirzenius/yuck!14
-rw-r--r--bibliography.yaml45
-rw-r--r--yuck.md96
2 files changed, 83 insertions, 58 deletions
diff --git a/bibliography.yaml b/bibliography.yaml
deleted file mode 100644
index 74d0e9d..0000000
--- a/bibliography.yaml
+++ /dev/null
@@ -1,45 +0,0 @@
----
-references:
-
-- id: rfc6749
- type: webpage
- author:
- - family: Hardt
- given: D.
- issued:
- - year: 2012
- month: 10
- title: The OAuth 2.0 Authorization Framework
- publisher: IETF
- url: https://tools.ietf.org/html/rfc6749
-
-- id: rfc8252
- type: webpage
- author:
- - family: Denniss
- given: W.
- - family: Bradley
- given: J.
- issued:
- - year: 2017
- month: 10
- title: OAuth 2.0 for native apps
- publisher: IETF
- url: https://tools.ietf.org/html/rfc8252
-
-- id: rfc8414
- type: webpage
- author:
- - family: Jones
- given: M.
- - family: Sakimura
- given: N.
- - family: Bradley
- given: J.
- issued:
- - year: 2018
- month: 6
- title: OAuth 2.0 Authorization Server Metadata
- publisher: IETF
- url: https://tools.ietf.org/html/rfc8414
-...
diff --git a/yuck.md b/yuck.md
index 5fc047c..27a5b81 100644
--- a/yuck.md
+++ b/yuck.md
@@ -106,7 +106,7 @@ the book service in such a way that the token is carried along. The
book service can now access the email service API with the access
token, and get what they need to print the books.
-[@rfc6749] describes the OAuth2 protocol in detail. This chapter
+[RFC 6749](#rfc6749) describes the OAuth2 protocol in detail. This chapter
condenses that into a shorter, and opinionated description.
## OAuth2 protocol variants (grant types)
@@ -114,7 +114,7 @@ condenses that into a shorter, and opinionated description.
OAuth2 allows for several different kinds of use cases, by providing
different ways to get an "authorization grant". An authorization grant
is a thing that provides access to a protected resource (see section
-1.3 in [@rfc6749]).
+1.3 in [RFC 6749](#rfc6749).
There are four authorization grant types:
@@ -307,7 +307,7 @@ but it still needs to find the actual complete URLs to the endpoints.
In the original OAuth 2.0 specification, this was left unspecified.
Each client needed to have inherent knowledge of the endpoints for each
-authorization server. RFC8414 [@rfc8414] adds a way for the client to find the
+authorization server. [RFC 8414](#rfc8414) adds a way for the client to find the
endpoints automatically, once it knows the authorization server
location.
@@ -389,8 +389,8 @@ form-encoded body that specifies that it wants to use the client
credentials grant. Specifically, it sets `grant_type` to
`client-credentials`. No other form fields are needed.
-The client provides its credentials as using [HTTP Basic Auth][], in
-the `Authorization` header.
+The client provides its credentials as using HTTP Basic Auth (see [RFC
+7616](#rfc7616)), in the `Authorization` header.
~~~{.numberLines}
POST /token HTTP/1.1
@@ -433,8 +433,6 @@ Note that for client credentials grants no refresh token is returned,
it would be fairly pointless. The client can just get a new access
token the same way it got the first one.
-[HTTP Basic Auth]: https://tools.ietf.org/html/rfc7617
-
### Error responses
A token request can fail for a variety of reasons. The 400 status code
@@ -444,7 +442,7 @@ server has an internal problem, 500 is returned.
For OAuth, a 400 response returns a more detailed indication about
what the client did wrong, in the `error` field in the JSON body of
-the response. RFC 6749 lists the [error codes][] and other fields. For
+the response. [RFC 6749](#rfc6749) lists the [error codes][] and other fields. For
example, if the client has the wrong credentials, the response would
look something like this:
@@ -470,10 +468,6 @@ failure.
FIXME: write this
-## JSON Web Token format
-
-[JSON Web Token]: https://tools.ietf.org/html/rfc7519
-
# Acknowledgement
Thank you to Ivan Dolgov and Pyry Heiskanen for reviewing merge
@@ -481,11 +475,87 @@ requests and general support when writing this document.
# References
+
+## RFC 7519 &ndash; JSON Web Token (JWT) {#rfc7519}
+
+* https://tools.ietf.org/html/rfc7519
+* M. Jones, J. Bradley, N. Sakimura
+* 2015
+
+Abstract:
+
+> JSON Web Token (JWT) is a compact, URL-safe means of representing
+> claims to be transferred between two parties. The claims in a JWT
+> are encoded as a JSON object that is used as the payload of a JSON
+> Web Signature (JWS) structure or as the plaintext of a JSON Web
+> Encryption (JWE) structure, enabling the claims to be digitally
+> signed or integrity protected with a Message Authentication Code
+> (MAC) and/or encrypted.
+
+
+
+## RFC 7616 &ndash; The 'Basic' HTTP Authentication Scheme {#rfc7616}
+
+* <https://tools.ietf.org/html/rfc7617>
+* J. Reschke
+* 2015
+
+Abstract:
+
+> This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
+> authentication scheme, which transmits credentials as user-id/
+> password pairs, encoded using Base64.
+
+
+
+## RFC 6759 &ndash; The OAuth 2.0 Authorization Framework {#rfc6749}
+
+* <https://tools.ietf.org/html/rfc6749>
+* D. Hardt, Ed.
+* 2012
+
+This is the core OAuth specification upon which all other ones build.
+Abstract:
+
+> The OAuth 2.0 authorization framework enables a third-party
+> application to obtain limited access to an HTTP service, either on
+> behalf of a resource owner by orchestrating an approval interaction
+> between the resource owner and the HTTP service, or by allowing the
+> third-party application to obtain access on its own behalf. This
+> specification replaces and obsoletes the OAuth 1.0 protocol
+> described in RFC 5849.
+
+## RFC 8252 &ndash; OAuth 2.0 for Native Apps {#rfc8252}
+
+* <https://tools.ietf.org/html/rfc8252>
+* W. Denniss, J. Bradley
+* 2017
+
+Abstract:
+
+> OAuth 2.0 authorization requests from native apps should only be
+> made through external user-agents, primarily the user's browser.
+> This specification details the security and usability reasons why
+> this is the case and how native apps and authorization servers can
+> implement this best practice.
+
+## RFC 8414 &ndash; OAuth 2.0 Authorization Server Metadata {#rfc8414}
+
+* <https://tools.ietf.org/html/rfc8414>
+* M. Jones, N. Sakimura, J. Bradley
+* 2018
+
+Abstract:
+
+> This specification defines a metadata format that an OAuth 2.0
+> client can use to obtain the information needed to interact with an
+> OAuth 2.0 authorization server, including its endpoint locations and
+> authorization server capabilities.
+
---
title: "OAuth2 and OpenID Connect: protocols and acceptance criteria"
author: Lars Wirzenius
documentclass: report
-bibliography: bibliography.yaml
bindings:
- yuck.yaml
classes: