Subject: [Txauth] Identity and session management

From: Justin Richer <[email-masked]>
Date: Thu, 13 Feb 2020 10:59:54 -0500

I’ve been doing some implementation of OIDC session management lately, and I had a realization that the pattern in TxAuth can give us a chance to do something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which client you are and which session you’re talking about. This is used as a drive-by client authentication (even though it’s really another bearer token sent through the front channel), which is what lets you do a post-logout redirect in a somewhat safe manner. The ID token is also used to carry session identifiers internally, and so it gets replayed as an assertion to reference those identifiers later on in the protocol. Basically, it’s building a lot of functionality on top of the ID token that it wasn’t really meant to bear. 

For TxAuth, I think we can follow a pattern similar to how we’re looking to handle user interaction to begin with:

- Client gets some kind of session management handle/identifier (and/or URL, depending on which model we go with). 
- When the user wants to log out, client can send that back to the AS in the back channel, and get back an interaction mechanism that the client can use to interact with the AS for determining if they want to kill the session there as well. 
- The AS can group together different clients into a “single sign out” cluster 
- When the AS learns that the user wants to log out, it might be able to push messages out to other clients — maybe they register back channel callback endpoints, or maybe a push message over http/2 or 3 or COAP, or some other mechanism. But the client can push that information in the initial request, and it can be user- and session- specific. 

These ideas aren’t fully baked, but it’s seeming to me that with this new pattern we’ve got a chance to make a much cleaner take on sessions than we were able to do before.

To be clear, I’m not saying any of this belongs explicitly in the charter, or that this is something that we need to tackle right now, but I think that addressing this eventually will make sense as part of the identity work as we move forward.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Feb 2020 08:35:57 -0800

On Thu, Feb 13, 2020 at 8:00 AM Justin Richer <[email-masked]> wrote:

> I’ve been doing some implementation of OIDC session management lately, and
> I had a realization that the pattern in TxAuth can give us a chance to do
> something a lot better.
>
> In OIDC, you use the ID token as a secondary artifact to indicate which
> client you are and which session you’re talking about. This is used as a
> drive-by client authentication (even though it’s really another bearer
> token sent through the front channel), which is what lets you do a
> post-logout redirect in a somewhat safe manner. The ID token is also used
> to carry session identifiers internally,

Is carrying the session identifiers specified somewhere, or is this an
implementation decision?

> and so it gets replayed as an assertion to reference those identifiers
> later on in the protocol. Basically, it’s building a lot of functionality
> on top of the ID token that it wasn’t really meant to bear.
>
> For TxAuth, I think we can follow a pattern similar to how we’re looking
> to handle user interaction to begin with:
>
> - Client gets some kind of session management handle/identifier (and/or
> URL, depending on which model we go with).
> - When the user wants to log out, client can send that back to the AS in
> the back channel, and get back an interaction mechanism that the client can
> use to interact with the AS for determining if they want to kill the
> session there as well.
> - When the AS learns that the user wants to log out, it might be able to
> push messages out to other clients — maybe they register back channel
> callback endpoints, or maybe a push message over http/2 or 3 or COAP, or
> some other mechanism. But the client can push that information in the
> initial request, and it can be user- and session- specific.
>

Mapping this to XAuth, a Client could update the Grant URI with a PUT to
logout all sessions, and as you mention, the GS could respond with an
interaction object for the Client to transfer interaction to the GS.

Other Clients could regularly read the Grant URI, and the logged in status
can be returned, or it could be a long lasting connection that returns a
logged out response if the User is logged out somewhere else.

>
> These ideas aren’t fully baked, but it’s seeming to me that with this new
> pattern we’ve got a chance to make a much cleaner take on sessions than we
> were able to do before.
>

Agreed. Neither is what I wrote above -- but with an established back
channel from Client to GS, there are interesting things that can be done.

>
> To be clear, I’m not saying any of this belongs explicitly in the charter,
> or that this is something that we need to tackle right now, but I think
> that addressing this eventually will make sense as part of the identity
> work as we move forward.
>

Agreed

>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Feb 2020 11:54:34 -0500

I would see the place for the session identifier to fit into the overall protocol is something that we’d specify, but the nature of the identifier itself would be opaque. In XYZ terms I’m seeing it as a separate handle, since it’s an independent artifact that lets the client control something. 

What’s important is that it needs to be separate from the transaction handle, which is tied more to the overall authorizations in the transaction and not necessarily the log-in session. We have run into many, many problems in the OIDC world because we’ve got a whole cavalcade of different things that aren’t tied very well together:

 - lifetime of the access token
 - lifetime of the refresh token
 - lifetime of the ID token
 - lifetime of access tokens gotten from a refresh token
 - session at the IdP
 - session at the RP
 - validity time of user’s grant decision policy (ie, “remember this” or “whitelist this”)

Sessions are really difficult, as evidenced by nobody really knowing what they mean when they say they want to log out.

 — Justin

> On Feb 13, 2020, at 11:35 AM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Thu, Feb 13, 2020 at 8:00 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> In OIDC, you use the ID token as a secondary artifact to indicate which client you are and which session you’re talking about. This is used as a drive-by client authentication (even though it’s really another bearer token sent through the front channel), which is what lets you do a post-logout redirect in a somewhat safe manner. The ID token is also used to carry session identifiers internally,
> 
> Is carrying the session identifiers specified somewhere, or is this an implementation decision?
>  
> and so it gets replayed as an assertion to reference those identifiers later on in the protocol. Basically, it’s building a lot of functionality on top of the ID token that it wasn’t really meant to bear. 
> 
> Mapping this to XAuth, a Client could update the Grant URI with a PUT to logout all sessions, and as you mention, the GS could respond with an interaction object for the Client to transfer interaction to the GS.
> 
> Other Clients could regularly read the Grant URI, and the logged in status can be returned, or it could be a long lasting connection that returns a logged out response if the User is logged out somewhere else.
>  
> 
> Agreed. Neither is what I wrote above -- but with an established back channel from Client to GS, there are interesting things that can be done.
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Feb 2020 09:14:34 -0800

Interesting!

That leads me to think that a Session might be yet a another object of the
Grant Request (using XAuth terms), that returns a Session URI that provides
for Session operations (CRUD) independent of the Grant request.

The Session operations could include updates for continuous authentication
such as CAEP.
ᐧ

On Thu, Feb 13, 2020 at 8:54 AM Justin Richer <[email-masked]> wrote:

> I would see the place for the session identifier to fit into the overall
> protocol is something that we’d specify, but the nature of the identifier
> itself would be opaque. In XYZ terms I’m seeing it as a separate handle,
> since it’s an independent artifact that lets the client control something.
>
> What’s important is that it needs to be separate from the transaction
> handle, which is tied more to the overall authorizations in the transaction
> and not necessarily the log-in session. We have run into many, many
> problems in the OIDC world because we’ve got a whole cavalcade of different
> things that aren’t tied very well together:
>
> Sessions are really difficult, as evidenced by nobody really knowing what
> they mean when they say they want to log out.
>
>  — Justin
>
>> I’ve been doing some implementation of OIDC session management lately,
>> and I had a realization that the pattern in TxAuth can give us a chance to
>> do something a lot better.
>>
>> To be clear, I’m not saying any of this belongs explicitly in the
>> charter, or that this is something that we need to tackle right now, but I
>> think that addressing this eventually will make sense as part of the
>> identity work as we move forward.
>>
>
> Agreed
>
>
>>
>> --
>> Txauth mailing list
>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Feb 2020 12:56:02 -0500

That tracks, since XAuth’s “objects” are in many ways analogous to XYZ’s “handle” structures, and what they represent. 

I think it’s separate from the tx/grant but they should be managed using parallel mechanisms to each other. That was the lightbulb that I had here. 

Plus the fact that the AS can tie together sessions from different clients, even doing smart seamless logins when it knows the user is present on another client right now. XYZ would manage that using user handles, probably.

But again, none of this is particularly well baked, but I am encouraged at the possibility of simplifying our approach to such a complex issue by taking a different view of it than we had in the past. 

 — Justin

> On Feb 13, 2020, at 12:14 PM, Dick Hardt <[email-masked]> wrote:
> 
> Interesting!
> 
> That leads me to think that a Session might be yet a another object of the Grant Request (using XAuth terms), that returns a Session URI that provides for Session operations (CRUD) independent of the Grant request.
> 
> The Session operations could include updates for continuous authentication such as CAEP.
> ᐧ
> 
> On Thu, Feb 13, 2020 at 8:54 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 13, 2020, at 11:35 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: David Waite <[email-masked]>
Date: Fri, 14 Feb 2020 02:24:50 -0700

> On Feb 13, 2020, at 9:35 AM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 

TL;DR - redirect-based logout flows are not only brittle (and becoming more brittle over time as browsers change their policies) but also growing out of fashion, outside of ‘aggregate’ applications where the different components are integrated via a single user agent and redirect-based SSO. We get far more value treating identity/authentication tokens similarly to access tokens - that they may have a defined lifetime, and may also be revoked via some back-channel mechanism, then we get by assuming there is some sort of common concept of authentication session.

I personally prefer to think of the “single logout” being revocation of an authentication token, rather than being related to any concept of distributed session. The security recommendations indicate you should not evaluate local access based on an expired or revoked authentication token. 

The relying party does not know the reasons behind the business policies for setting a token lifetime or for doing revocation, nor do they know up-front whether the process of getting a new authentication token can be done back-channel with no interaction, nor whether active user interaction (such as authentication) is required to succeed. They just know they shouldn’t rely on an invalidated token.

Traditional redirect-based SSO works because the same user agent is involved and serves as bearer for messages between the RP and IDP. SLO exists to serve two needs here:
1. User expectation is that within the same user agent, access as a user is either universally available or universally denied. The “Logout” button in this scenario is a signal from the user that they may not be the next entity that interacts with the system, and that authentication should be reacquired.
2. The user or an operation may expect the ability to revoke consent (and associated access) to users/clients/relying parties/user agents on demand.

Much of the SLO deployment today is to satisfy the first case, and will rely on the fact that authentication took place via redirects on the same user agent in order to delete artifacts of the original SSO, such as session cookies. 

The redirect-based technique used to implement SLO today however does not serve the needs of the second case, and even with the first case its usability is being eroded by privacy efforts in browsers destabilizing cookie usage in multi-party scenarios.

For TXAuth, the IDP interaction may be entirely on some other user agent, such as via the device flow or a CIBA-like flow. Once you abstract out the mechanism of interaction to this extent, the use of redirect-based flows becomes untenable.

You also have a changing user expectation that the authentication serves merely as a linking of personas between the two parties, and that each will do their own access management after that point. For example, an application like Slack (whether in web or native app user deployment) does not log the user out merely because the backing Google/GSuite account logged out.  IMHO this expectation is even stronger in cases where you are using multiple user agents, possibly spanning multiple devices. 

Some of this has been served by the mobile initiative over the last dozen years or so pushing for devices to be treated as being single user and/or managed access - the authentication security policy has gone in many places from being implemented within the browser to being implemented at the device level. An enterprise application may use identity tokens to determine that it is in compliance, but the actual tokens themselves may come from the managed device policy.

In both of these cases, scenario 2 is more likely - that the user consent for an app has gone away, or that access is being revoked because a device has gone out of compliance.

The case where scenario 1 is still most needed is consumer web applications developed with delegated authentication (SAML, OIDC) as the integration between components. I believe this is possible to support, although the components would be limited to integration via the interaction endpoint. IMHO the only reason this would need some sort of signed message or identifier would be to prevent XSRF abuse.
 
<snip>

> - The AS can group together different clients into a “single sign out” cluster 

Note that for many applications, it does not make sense that the client would (to try to stay closer to my earlier parlance) signal that the AS should revoke other authentications, as the client does not dictate nor understand AS policy nor the policy or user expectations of other applications. User-initiated logout on a managed device for example would likely be a no-op.

As you say, the only sort of application I have seen where this makes sense is the previously mentioned aggregate of web applications via delegated authentication. GSuite, for example, adds a two-click method to cancel access to every GSuite application - but they do not expose any logout mechanism to third party applications (at least via their metadata.) It is also worth noting that this is done via embedded frames, as a redirect-based mechanism would be insufficient.

If a client has the capability to revoke different kinds of tokens, then the revocation of an authentication token within a client could be taken as a signal to revoke multiple tokens based on some grouping. This could leverage something like OIDC’s sector identifier uri, although the issuer of the tokens would still need to have some sort of dynamic correlation to only revoke tokens issued to those clients on the same device or within the same user agent. This is usually implemented today via web redirects and IDP state stored within cookies - but this approach has begun to break down with browser efforts to limit cross-site cookie abuses.

> - When the AS learns that the user wants to log out, it might be able to push messages out to other clients — maybe they register back channel callback endpoints, or maybe a push message over http/…

With externally revoked access tokens, the client does not need a signal since the protected resources should be evaluating validity. With authentication tokens, the client needs to have a way to check validity.

The center of TXAuth is likely to be an interactor that coordinates with the various parties. I expect numerous extensions to define particular interaction strategies for all the parties involved, and not just the authorizing/authenticating user agent as we have today with multiple OAuth grant types/“flows”.

So a client might get revocation messages via web push, via SET mechanisms, or do so via polling. I proposed an API for poliing a while back for OIDC which may be repurposed   (the API was designed with some additional complexity under the assumption that there may be multiple providers for the token revocation information). https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt

> Agreed. Neither is what I wrote above -- but with an established back channel from Client to GS, there are interesting things that can be done..
>  
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 14 Feb 2020 10:15:42 -0500

I think there are multiple use cases and perspectives when it comes to 
session management and usability on the web.

As for perspectives, we have:
1. The user and the experience they are expecting
2. The relying party and how they are viewing authentication and session 
management

As for use cases, we have:
1. Relying parties that support Federated Authentication and then manage 
the resulting session themselves. In this context the session is really 
an RP session and NOT and IDP session.
2. Relying parties that want to be tightly bound to the IDP session. 
This is often true of services that are "1st party" to the domain of the 
IDP (e.g. Yahoo services and the Yahoo IDP).

Let's call use case (1) RP-Bound Session management and use case (2) 
IDP-Bound session management.

 From the users perspective, the "order of operations" also matters. 
Take the following scenarios.

 1. User goes to hikingtrail.example and clicks the "Sign in with
    Google" button. The user is both SSO'd into Google properties and
    also logged into hikingtrail.example. The user only has one tab open
    for hikingtrail.example and when the user is finished with their
    activities at hikingtrail.example, they click the logout button.
     1. If hikingtrail.example is using the RP-Bound session model, they
        log the user out of hikingtrail.example but the user is still
        logged in at Google. If the user were to click the signin
        button, they would be silently signed in with a new RP-Bound
        session. This can be confusing to users because they may have
        expected to be logged out of Google as the only open tab was for
        hikingtrail.example.
     2. If hikingtrail.example is using the IDP-Bound session model,
        then it needs a way to signal to Google that the user wants the
        IDP session to be revoked when the user clicks the logout button
        on hikingtrail.example. From an IDP with "1st party" services
        perspective, it's "dangerous" to provide this mechanism to
        relying parties.
 2. User goes to Google and logs in to read their mail. The user then
    opens a second tab and navigates to hikingtrail.example and clicks
    the "Sign in with Google" button and is seamlessly logged in. When
    the user finishes and clicks the "logout" button on
    hikingtrail.example they are logged out of the site.
     1. If hikingtrail.example is using the RP-Bound session model, the
        site clears it's session and displays the logged out version of
        the site. This is exactly what the user expects. If the user
        clicks the "Sign in with Google" button they will be seamlessly
        logged in and that is also what the user expects because they
        still have tab open for gmail.
     2. If hikingtrail.example is using the IDP-Bound session model, the
        user gets logged out of their gmail experience as well as
        hikingtrail.example. This is something the IDP (if it provides
        1st party services) does not want to happen.

Today, many of the SaaS products we use in the enterprise use a RB-Bound 
session model.  We seem to manage. However, there are some services that 
require an IDP-Bound session model and those are at times annoying 
because I get logged out of the enterprise IDP just be logging out of 
the SaaS tool.

Maybe one option that could be explored is allowing an RP to indicate to 
the IDP that it does not want an IDP-Session to be created for this 
user/device if one doesn't currently exist. Today this would manifest as 
the IDP NOT setting SSO cookies on it's own domain and just returning 
the federated authentication tokens.

Hopefully that is helpful in some way :)

On 2/14/20 4:24 AM, David Waite wrote:
>> On Feb 13, 2020, at 9:35 AM, Dick Hardt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>     I’ve been doing some implementation of OIDC session management
>>     lately, and I had a realization that the pattern in TxAuth can
>>     give us a chance to do something a lot better.
>>
>>     In OIDC, you use the ID token as a secondary artifact to indicate
>>     which client you are and which session you’re talking about. This
>>     is used as a drive-by client authentication (even though it’s
>>     really another bearer token sent through the front channel),
>>     which is what lets you do a post-logout redirect in a somewhat
>>     safe manner. The ID token is also used to carry session
>>     identifiers internally,
>>
>>
> TL;DR - redirect-based logout flows are not only brittle (and becoming 
> more brittle over time as browsers change their policies) but also 
> growing out of fashion, outside of ‘aggregate’ applications where the 
> different components are integrated via a single user agent and 
> redirect-based SSO. We get far more value treating 
> identity/authentication tokens similarly to access tokens - that they 
> may have a defined lifetime, and may also be revoked via some 
> back-channel mechanism, then we get by assuming there is some sort of 
> common concept of authentication session.
>
> I personally prefer to think of the “single logout” being revocation 
> of an authentication token, rather than being related to any concept 
> of distributed session. The security recommendations indicate you 
> should not evaluate local access based on an expired or revoked 
> authentication token.
>
> The relying party does not know the reasons behind the business 
> policies for setting a token lifetime or for doing revocation, nor do 
> they know up-front whether the process of getting a new authentication 
> token can be done back-channel with no interaction, nor whether active 
> user interaction (such as authentication) is required to succeed. They 
> just know they shouldn’t rely on an invalidated token.
>
> Traditional redirect-based SSO works because the same user agent is 
> involved and serves as bearer for messages between the RP and IDP. SLO 
> exists to serve two needs here:
> 1. User expectation is that within the same user agent, access as a 
> user is either universally available or universally denied. The 
> “Logout” button in this scenario is a signal from the user that they 
> may not be the next entity that interacts with the system, and that 
> authentication should be reacquired.
> 2. The user or an operation may expect the ability to revoke consent 
> (and associated access) to users/clients/relying parties/user agents 
> on demand.
>
> Much of the SLO deployment today is to satisfy the first case, and 
> will rely on the fact that authentication took place via redirects on 
> the same user agent in order to delete artifacts of the original SSO, 
> such as session cookies.
>
> The redirect-based technique used to implement SLO today however does 
> not serve the needs of the second case, and even with the first case 
> its usability is being eroded by privacy efforts in browsers 
> destabilizing cookie usage in multi-party scenarios.
>
> For TXAuth, the IDP interaction may be entirely on some other user 
> agent, such as via the device flow or a CIBA-like flow. Once you 
> abstract out the mechanism of interaction to this extent, the use of 
> redirect-based flows becomes untenable.
>
> You also have a changing user expectation that the authentication 
> serves merely as a linking of personas between the two parties, and 
> that each will do their own access management after that point. For 
> example, an application like Slack (whether in web or native app user 
> deployment) does not log the user out merely because the backing 
> Google/GSuite account logged out.  IMHO this expectation is even 
> stronger in cases where you are using multiple user agents, possibly 
> spanning multiple devices.
>
> Some of this has been served by the mobile initiative over the last 
> dozen years or so pushing for devices to be treated as being single 
> user and/or managed access - the authentication security policy has 
> gone in many places from being implemented within the browser to being 
> implemented at the device level. An enterprise application may use 
> identity tokens to determine that it is in compliance, but the actual 
> tokens themselves may come from the managed device policy.
>
> In both of these cases, scenario 2 is more likely - that the user 
> consent for an app has gone away, or that access is being revoked 
> because a device has gone out of compliance.
>
> The case where scenario 1 is still most needed is consumer web 
> applications developed with delegated authentication (SAML, OIDC) as 
> the integration between components. I believe this is possible to 
> support, although the components would be limited to integration via 
> the interaction endpoint. IMHO the only reason this would need some 
> sort of signed message or identifier would be to prevent XSRF abuse.
> <snip>
>
>>     - When the user wants to log out, client can send that back to
>>     the AS in the back channel, and get back an interaction mechanism
>>     that the client can use to interact with the AS for determining
>>     if they want to kill the session there as well.
>>
> Note that for many applications, it does not make sense that the 
> client would (to try to stay closer to my earlier parlance) signal 
> that the AS should revoke other authentications, as the client does 
> not dictate nor understand AS policy nor the policy or user 
> expectations of other applications. User-initiated logout on a managed 
> device for example would likely be a no-op.
>
> As you say, the only sort of application I have seen where this makes 
> sense is the previously mentioned aggregate of web applications via 
> delegated authentication. GSuite, for example, adds a two-click method 
> to cancel access to every GSuite application - but they do not expose 
> any logout mechanism to third party applications (at least via their 
> metadata.) It is also worth noting that this is done via embedded 
> frames, as a redirect-based mechanism would be insufficient.
>
> If a client has the capability to revoke different kinds of tokens, 
> then the revocation of an authentication token within a client could 
> be taken as a signal to revoke multiple tokens based on some grouping. 
> This could leverage something like OIDC’s sector identifier uri, 
> although the issuer of the tokens would still need to have some sort 
> of dynamic correlation to only revoke tokens issued to those clients 
> on the same device or within the same user agent. This is usually 
> implemented today via web redirects and IDP state stored within 
> cookies - but this approach has begun to break down with browser 
> efforts to limit cross-site cookie abuses.
>
>>     - When the AS learns that the user wants to log out, it might be
>>     able to push messages out to other clients — maybe they register
>>     back channel callback endpoints, or maybe a push message over
>>     http/2 or 3 or COAP, or some other mechanism. But the client can
>>     push that information in the initial request, and it can be user-
>>     and session- specific.
>>
>
> With externally revoked access tokens, the client does not need a 
> signal since the protected resources should be evaluating validity. 
> With authentication tokens, the client needs to have a way to check 
> validity.
>
> The center of TXAuth is likely to be an interactor that coordinates 
> with the various parties. I expect numerous extensions to define 
> particular interaction strategies for all the parties involved, and 
> not just the authorizing/authenticating user agent as we have today 
> with multiple OAuth grant types/“flows”.
>
> So a client might get revocation messages via web push, via SET 
> mechanisms, or do so via polling. I proposed an API for poliing a 
> while back for OIDC which may be repurposed   (the API was designed 
> with some additional complexity under the assumption that there may be 
> multiple providers for the token revocation information). 
> https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt
>
>> Mapping this to XAuth, a Client could update the Grant URI with a PUT 
>> to logout all sessions, and as you mention, the GS could respond with 
>> an interaction object for the Client to transfer interaction to the GS.
>>
>> Other Clients could regularly read the Grant URI, and the logged in 
>> status can be returned, or it could be a long lasting connection that 
>> returns a logged out response if the User is logged out somewhere else.
>>
>>
>>     These ideas aren’t fully baked, but it’s seeming to me that with
>>     this new pattern we’ve got a chance to make a much cleaner take
>>     on sessions than we were able to do before.
>>
>>
>> channel from Client to GS, there are interesting things that can be 
>> done..
>>
>>
>>     charter, or that this is something that we need to tackle right
>>     now, but I think that addressing this eventually will make sense
>>     as part of the identity work as we move forward.
>>
>>
>> Agreed
>>
>>
>>     -- 
>>     Txauth mailing list

---

From: George Fletcher <[email-masked]>
Date: Fri, 14 Feb 2020 10:15:42 -0500

---

From: David Waite <[email-masked]>
Date: Fri, 14 Feb 2020 14:51:39 -0700

> On Feb 14, 2020, at 8:15 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> I think there are multiple use cases and perspectives when it comes to session management and usability on the web. 
> 
> 2. The relying party and how they are viewing authentication and session management
> 
> 1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session. 
> 2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP).

Yes, an id_token exchange in OpenID Connect could be considered to be three things:

1. A mechanism for correlation between accounts/personas of two parties
2. A mechanism to convey authentication events by that persona on the IDP/OP, for dependence by the RP, in the context of a particular user agent
3. Claims about that persona on the IDP/OP, to enrich or enable policy decisions by the RP

Many/most RPs either do not care about #2, or only care about authentication in the context of their own initiation of SSO. They do not attempt to track ongoing authentication events by the IDP/OP to control local access by the user agent.

Arguably one of the values of OAuth and delegated authorization is that the enforcement of authorization is often under the control of the same parties as the AS. However with authentication scenarios, the authorization decisions and enforcement are made by the RP.

> User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button.
> If hikingtrail.example is using the RP-Bound session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example.
> If hikingtrail.example is using the IDP-Bound session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. From an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying parties.
My expectation (principal of least surprise), would be that for a third party application like hikingtrail, ‘Sign in with Google’ or ‘Log in with Facebook’ does just that - it gives access based on Google. I would not expect the sessions of two completely separate applications to be bound.

If anything, I would expect that the OP would indicate better that the user may be creating a second authentication session with the OP as a side effect. This could even result in a “remember me” or “personal machine” sort of checkbox, where the checked box is what enables SSO. Unchecked, each authentication request by a third-party RP would require new authentication.

I don’t know of a concise and obvious way to indicate to the user that the sessions of two applications are being bound - I don’t think changing the verbiage of the button to something like “Connect with Google” is sufficient. I suspect this winds up needing holistic cues of deeper integration - for instance this might be ideal with third party ‘editors’ for Google Drive.
> User goes to Google and logs in to read their mail. The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site.
> If hikingtrail.example is using the RP-Bound session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail.
> If hikingtrail.example is using the IDP-Bound session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen.
> Today, many of the SaaS products we use in the enterprise use a RB-Bound session model.  We seem to manage. However, there are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS tool.
> 
I don’t believe best practices of distributed sessions are anywhere close to being documented or understood by developers or integrators. In some enterprise applications I see any ‘logout’ button disconnected. In others, I see it going to a protocol or other endpoint to revoke as much access as possible.

If I’ve seen patterns here, it is that a working logout button is either connected merely because it is possible, or because the RP application has a certain level of access to sensitive data. 
> Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens.
> 
Yes, although I think the typical user has more exposure to understand the ramifications of a ‘remember me’ checkboxes, so this may (like most request parameters) only serve as a hint.
> Hopefully that is helpful in some way :)

Of course!

-DW