From ad383351c2e5263556ee73ee95082e17c4ff2483 Mon Sep 17 00:00:00 2001 From: Isaiah Inuwa Date: Fri, 29 Nov 2019 10:16:23 -0600 Subject: [PATCH 1/3] Rename nonce to txn_id. Reorganize for clarity. Signed-Off-By: Isaiah Inuwa --- specification/client_server_api.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index 84cde946..50ffff8f 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -740,22 +740,23 @@ To use this authentication type, clients should submit an auth dict as follows: "session": "" } -The ``nonce`` should be a random string generated by the client for the -request. The same ``nonce`` should be used if retrying the request. A client may receive a login ``token`` via some external service, such as email or SMS. Note that a login token is separate from an access token, the latter providing general authentication to various API endpoints. -The ``txn_id`` may be used by the server to disallow other devices from using -the token, thus providing "single use" tokens while still allowing the device -to retry the request. This would be done by tying the token to the ``txn_id`` +Additionally, the server must encode the user id in the ``token``; there is +therefore no need for the client to submit a separate username. + +The ``txn_id`` should be a random string generated by the client for the +request. The same ``txn_id`` should be used if retrying the request. The +``txn_id`` may be used by the server to disallow other devices from using the +token, thus providing "single use" tokens while still allowing the device to +retry the request. This would be done by tying the token to the ``txn_id`` server side, as well as potentially invalidating the token completely once the device has successfully logged in (e.g. when we receive a request from the newly provisioned access_token). -The server must encode the user id in the ``token``. There is therefore no need -for the client to submit a separate username. OAuth2-based <<<<<<<<<<<< From 7cfc4b09a69766c66484771918e804b7fed79e51 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Sat, 7 Dec 2019 15:31:42 -0700 Subject: [PATCH 2/3] Changelog --- changelogs/client_server/newsfragments/2369.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2369.clarification diff --git a/changelogs/client_server/newsfragments/2369.clarification b/changelogs/client_server/newsfragments/2369.clarification new file mode 100644 index 00000000..c7fd0fd9 --- /dev/null +++ b/changelogs/client_server/newsfragments/2369.clarification @@ -0,0 +1 @@ +Minor clarifications to token-based User-Interactive Authentication. From ccc7bcabbc2625618bd884b641b78de1e52eba90 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Sat, 7 Dec 2019 15:32:43 -0700 Subject: [PATCH 3/3] id -> ID while we're here --- specification/client_server_api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index 50ffff8f..eb32d3b4 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -745,7 +745,7 @@ A client may receive a login ``token`` via some external service, such as email or SMS. Note that a login token is separate from an access token, the latter providing general authentication to various API endpoints. -Additionally, the server must encode the user id in the ``token``; there is +Additionally, the server must encode the user ID in the ``token``; there is therefore no need for the client to submit a separate username. The ``txn_id`` should be a random string generated by the client for the