Warning:
This wiki has been archived and is now read-only.
Dialback authentication/archive
This is an outline for a dialback authentication mechanism for HTTP. It provides a method of authentication for server-to-server communications to associate HTTP client calls with a Host name or Webfinger account.
Contents
Use cases
- For pubsubhubbub, to associate a subscription with a particular user
- For OAuth client registration, to associate a client key with a user or domain
New Authorization type
This spec adds a new Authorization type, "Dialback". The header has the following optional elements:
- host The host authorizing the request
- webfinger The webfinger account authorizing the request
- nonce An opaque value used to confirm the request authorization
Exactly one of "host" or "webfinger" is required.
"nonce" is always required.
Replay prevention
To prevent replay attacks, the server has to reject the request if it's already seen the same (host | webfinger, nonce, date) tuple.
To keep from having to save billions of tuples until the end of time, it's reasonable to reject requests with a Date: outside a fixed window. +/- 5 minutes from server time is what's recommended for OAuth.
Discovery
The server receiving the request uses hostmeta (for hosts) or webfinger (for webfingers) to discover a link with type "dialback".
This link is an URL that can handle dialback requests.
Dialback request
To confirm, the server makes an HTTP POST request to the dialback endpoint with the following arguments:
- host: The host value provided in the original Authorization header.
- webfinger: The webfinger value provided in the original Authorization header.
- nonce: The nonce provided in the original Authorization header.
- url: The URL that the original request was made to.
- date: The Date header on the original request. If there was no Date header, this should be omitted.
One of "host" or "webfinger" is required. "nonce" and "url" are required.
Examples
Host authentication
- The client sends an HTTP request with an Authorization header:
POST /some/endpoint HTTP/1.1 Host: photo.example Date: Tue, 28 Aug 2012 09:41:21 -0400 Content-Type: application/x-www-url-form-encoded Authorization: Dialback host="checkin.example" nonce="4430086dedf5b9143c66"
arg1=186&arg2=50
- The server checks that the Date: header is within an acceptable window (+/- 5 minutes recommended).
- The server checks that it hasn't seen this (host, nonce, date) tuple before.
- The server discovers a dialback confirmation endpoint at checkin.example. Its rel type is "dialback".
- The server posts an HTTP request to confirm the nonce:
POST /dialback HTTP/1.1 Host: checkin.example Date: Tue, 28 Aug 2012 09:41:43 -0400 Content-Type: application/x-www-url-form-encoded host=checkin.example&nonce=4430086dedf5b9143c66&url=http://photo.example/some/endpoint&date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400
- checkin.example returns 200 OK for a confirmation, 4xx for confirmation failure, 5xx for server failure.
Webfinger authentication
- The client sends an HTTP request with an Authorization header:
GET /some/resource HTTP/1.1 Host: photo.example Date: Tue, 28 Aug 2012 09:41:21 -0400 Authorization: Dialback webfinger="alice@checkin.example" nonce="b3265cd56bf7b0dd5a26"
- The server checks that the Date: header is within an acceptable window (+/- 5 minutes recommended).
- The server checks that it hasn't seen this (webfinger, nonce, date) tuple before.
- The server discovers a dialback confirmation endpoint for alice@checkin.example. Its rel type is "dialback".
- The server posts an HTTP request to confirm the nonce:
POST /dialback HTTP/1.1 Host: checkin.example Date: Tue, 28 Aug 2012 09:41:43 -0400 Content-Type: application/x-www-url-form-encoded webfinger=alice@checkin.example&nonce=b3265cd56bf7b0dd5a26&url=http://photo.example/some/resource&date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400
- checkin.example returns 200 OK for a confirmation, 4xx for confirmation failure, 5xx for server failure.
Notes
- The "host" or "webfinger" parameters in the dialback request allow a single dialback endpoint to handle multiple domains or accounts.
- The "nonce" is absolutely required.
- This mechanism should work for all HTTP methods (GET, POST, HEAD, OPTIONS, PUT, ...).
Implementation
- The client can store request data in a database, keeping tuples like (host, url, date, long-random-nonce). At dialback time, it can check that it has such a record stored.
- The client can use nonces that are a digital signature of a known format, like signature(host, url, date, secret-key). At dialback time, it can re-sign the arguments with its secret key and make sure the result matches the passed-in nonce.
Concerns
- This can only confirm that "checkin.example" is responsible for the request.
- There is no confirmation that the user "alice@checkin.example" has authorized the request independently from checkin.example.
- Arguments aren't included in the dialback. Do they need to be?
- Does anything need to be digitally signed? If so, why?
- Is URL parameter OK? Does it need to be "URI" or "IRI" or something more politically correct?
- Is the URL parameter required? Will this work without an URL parameter?
- Is the date parameter required? Will this work without a date parameter?
- There are lots of extra HTTP requests required to authenticate the original HTTP request. I think caching the results of host-meta and webfinger requests should make this more manageable, but each request will still require at least one dialback request.
- It would probably be possible to have just a single parameter to replace "host" and "webfinger" -- "principal" or "subject"? But you'd have to be able to tell the difference between a host and a Webfinger address to know which one to do discovery on.
References
- RFC 2069 - An Extension to HTTP : Digest Access Authentication