The future belongs to OpenID Connect. More and more services drift away from using SAML as authentication protocol since it is not actively developed anymore and lacks support for use cases like mobile or single-page applications or OAuth 2.0. As you probably know, the Switch edu-ID has already been providing support for OpenID Connect (or short OIDC) for several years. Services can already use OIDC in order to authenticate users with the edu-ID and get the required information about them to provide a good and seamless user experience, just like for SAML. However, you might also have noticed that the edu-ID OIDC support does not yet cover all capabilities which are covered by SAML.
Therefore, a focus towards the end of last year and continuing this year is to improve the overall OIDC and OAuth 2.0 support of the Switch edu-ID and therewith simplify the migration away from SAML towards a new, more future-proof protocol.
Among others, the most important improvements that have been implemented were the following:
-
- Logout and logout propagation is now available for OIDC clients. See details here.
- OIDC clients can now request the same attributes like for SAML within the extended attribute model. The complete list is available here.
- Tokens can now be configured per client. There are different types of clients, and they have different needs when it is about token types, token lifetimes, and claim sets in the tokens. See here for details.
- Several measures were taken so that malicious attempts to impersonate a client or the usage of fished tokens can be prevented better.
- The handling of CORS allowed origins has been revised. This makes it easier for single page application clients to be registered within the federation.
- The public documentation of OIDC with the edu-ID has been improved.
And now, what’s next?
The concept of affiliations linked to a user-centric identity is the actual advantage of the edu-ID over the former AAI concept. This lets users log in to services either as a private person or with an identity from one of their affiliations, with a tailored set of attributes coming from the corresponding institutions. For OIDC, by now only the extended attribute model is supported, meaning that services can only receive attributes from the private identity of the user, plus some information about what affiliations the user has. But they can’t yet get the whole organisational identity, as this is the case for SAML with the classic attribute model. Supporting this also for OIDC is the next big thing we want to implement.
However, we depend on your feedback on how we should implement the classic attribute model for Switch edu-ID with OIDC. We don’t just want to do it, we want to do it right. Therefore, we have prepared a Request for Comments (RFC) with a proposed specification. If you are interested in this topic, please read the related information provided on https://help.switch.ch/eduid/docs/gen/rfc/rfc2026oidc/ together with the RFC. If you have any feedback or use cases which might not be covered by the proposed solution, please let us know until Friday 6 March as indicated there.