Hi folks, this topic probably needs further investigation. I'll share my findings and welcome any ideas on how to further debug this. Maybe someone else has encountered the same problem? We're using Satosa as the basis for various of our deployments. This issue occurs in any v7 version of Satosa and is not limited to only the most recent 7.0.3. The pySAML2 security vulnerability only was the trigger for me to finally upgrade from 6.1.0 which we have been using until now. This upgrade also includes raising the pyop dependency from 3.0.1 to 3.1.0 for what it's worth. I removed as much of our custom config and code as possible, notably switching back to the vanilla OIDC frontend without any modifications. Basically, MongoDB entries for subject-identifier are being deleted whenever another access token is generated (i.e. another user logs in). This leads to all previous access tokens being unusable for accessing userinfo etc.: [Wed Jan 27 13:00:49 2021] [wsgi] [ERROR] [satosa.base] [/usr/local/lib/python3.6/site-packages/satosa/base.py - line 257]: [urn:uuid:652c74dc-bab6-46a4-8be8-d83fa215a281] Uncaught exception ... [Wed Jan 27 13:00:49 2021] [wsgi]   File "/usr/local/lib/python3.6/site-packages/pyop/authz_state.py", line 315, in get_user_id_for_subject_identifier [Wed Jan 27 13:00:49 2021] [wsgi]     raise InvalidSubjectIdentifier('{} unknown'.format(subject_identifier)) [Wed Jan 27 13:00:49 2021] [wsgi] pyop.exceptions.InvalidSubjectIdentifier: 00000000-0000-0000-0000-000000000002 unknown Consider the following example: 1) Login with Account 1 (sub=00000000-0000-0000-0000-000000000002) 2) Login with Account 2 in another browser (sub=ddd3a947-b5e1-4f59-a757-eab8231aa687) With 6.1.0 MongoDB would now look like this: {     _id: ObjectId('60115fab8486770baffef551'),     lookup_key: 'superadmin',     data: {         'public': '00000000-0000-0000-0000-000000000002'     },     modified_ts: 1611751339.31406 } {     _id: ObjectId('60115fe08486770baffef5f5'),     lookup_key: 'a at b.de',     data: {         'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687'     },     modified_ts: 1611751392.2613952 } With 7.x MongoDB contains *only* the following entry instead: {     _id: ObjectId('60115fe08486770baffef5f5'),     lookup_key: 'a at b.de',     data: {         'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687'     },     modified_ts: 1611751392.2613952 } If that makes any difference, we're only using public sub claims:   fe_id:     openid: [sub] which are generated from LDAP attributes:       search_return_attributes:         didmosUUID: fe_id I have not yet tested with pairwise claims. Any ideas are much appreciated :) Cheers, David -- David Hübner, Solutions Engineer DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: david.huebner at daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz