From 9ad03d71d7e939518174ec3bd44f56f10061d049 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sun, 21 Feb 2021 15:33:28 +0200 Subject: refactor: use hyperlinks instead of BibTeX for references --- bibliography.yaml | 45 -------------------------- yuck.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 83 insertions(+), 58 deletions(-) delete mode 100644 bibliography.yaml 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 – 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 – The 'Basic' HTTP Authentication Scheme {#rfc7616} + +* +* 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 – The OAuth 2.0 Authorization Framework {#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 – OAuth 2.0 for Native Apps {#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 – OAuth 2.0 Authorization Server Metadata {#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: -- cgit v1.2.1