Be Ready for the AUTHpocalypse – Lightweight/Dynamic Client Registration for IMAP/SASL

From IIW

Session Topic: Be Ready for the Authpocalypse: Lightweight/Dynamic Client Registration for ImAP/SASL

Wednesday 5A

Convener: John Bradley/Breno/Naveen

Notes-taker(s): Roshni Chandrashekhar

Tags for the session - technology discussed/ideas considered: Dynamic Client Registration

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: Dynamic Client Registration

Issues tabled for later: -- discovery

Consider the example of ThunderBird (TB):

A user downloads TB and it uses OAuth2, but it doesn’t know which authz server to use. OAuth2 requires a client ID, and when the user enters X@gmail.com, there needs to be some way to send a client ID to the authz server.


Disadvantage of WebFinger --

not every enterprise has a web server with a TLS cert that it can put WebFinger info on.


Segue:

Assume you have the oauth token. You want to access 4 different services with the same token -- IMAP, SMTP, Address Book HTTP, Calendar HTTP

-- use one downscoped token for the difference security contexts of the different protocols?


We cannot assume that all the endpoints for these 4 services are in the same location, because we know this to not be the case in several cases. However, it is trivial for the client to find that the issuer is not the same for all these services and handle that. If the issuer is the same, then the client should combine and ask for multiple scope consent.


Scenario:

IMAP -----------------------> AUTH ------------------------> CLIENT REG


Options:

1. Any public client gets a fixed client ID and everybody supports it. For example clientID=IMAP.

  • -- branding issues on the approval page
  • + avoids each client making a registration request and then an OAuth call.

2. JWT from vendor (containing client info and PoP)

3. Public key for instance.

  • -- prevents intercepted code in response
  • -- protects code but not refresh token


1&2 identifies client. 3 authenticates client.


4. Dynamic Client Registration

5. Stateless dynamic client registration where client ID is the server assertion.


Q. AS, do you have a client that redirects to this URL? Give me that client ID.

A. Not secure, susceptible to interception.


Goal: to keep the code from being used if intercepted, which is what client ID is used for.


We can recognize that the assertion in (2 -- Vendor JWT) is the same across a range of clients.


“Software Statement” -- a statement signed by the software developer with some parameters that helps to identify the software through which the request is made.


Use assertion flow only and a public key -- makes discussions about statelessness simpler.

  • -- client generates its own public/private key pair
  • -- no security implications of encryption
  • -- use JWT assertion for client authentication


Q. Does every instance of installed client end up with its own client ID and secret?

A. Yes. But the server doesn’t store it. Use public keys to give each instance its own client ID.


Confidential clients

-- you don’t need to protect the request if you have a confidential client.

-- the software statement as client ID for all authz flows implies you need to give up the option of making clients confidential and use PoP for code instead.


The current dynamic client registration spec supports both public and confidential clients. Using the software statement implies you can now track installed clients as separate instances.

Class differentiation is made easier to handle. (For Example: A loses laptop, we should allow A to disable access through the laptop but not ask for re-auth on a phone and other devices)


If the authz server has to support only one kind of dynamic client registration, it reduces the pain for the implementation of an IMAP client.


Summary:

Current spec of dynamic client registration

+ add software statement so authz server knows what software is making the request

+ authz server choice of stateless/stateful

+ make it mandatory to implement specific authz mechanism by IMAP client

Retrieved from "https://iiw.idcommons.net/index.php?title=Be_Ready_for_the_AUTHpocalypse_–_Lightweight/Dynamic_Client_Registration_for_IMAP/SASL&oldid=19596"