libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

Update topics/overview/supported-protocols.adoc

Browse source
This commit is contained in:
Stian Thorgersen 2016-06-10 06:37:45 +02:00
parent b7d5704db9
commit 8d850ce0cf
1 changed files with 10 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
topics/overview/supported-protocols.adoc
View file

@ -39,20 +39,17 @@ is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks {{book.project.name}}
to obtain an SAML assertion it can use to invoke on other remote services on behalf of the user.
=== OIDC vs. SAML
=== OpenID Connect vs. SAML
Choosing between OpenID Connect and SAML is not just a matter of using a newer protocol (OIDC) instead of the older more mature protocol (SAML).
In most cases {{book.project.name}} recommends using OIDC.
Choosing between OIDC and SAML is not just a matter of using a newer, sexier protocol (OIDC) instead of the old, mature, dinosaur (SAML).
{{book.project.name}} has chosen OIDC as the protocol we use to both recommend and write all our extensions on top of.
SAML tends to be a bit more verbose than OIDC.
Beyond verbosity of exchanged data, if you compare the specifications you'll find that OIDC was designed to work with the
web while SAML was retrofitted to work on top of the web. For example,
OIDC is also much better suited for HTML5/JavaScript applications because it is
much much simpler to implement on the client side than SAML. Since tokens are in the JSON format,
they can be directly consumed by JavaScript. Also, you'll find many nice little switches and features that
make implementing security in your web applications easier. For example, check out the iframe trick that the specification
uses to easily determine if a user is still logged in or not.
Beyond verbosity of exchanged data, if you compare the specifications you'll find that OIDC was designed to work with the web while SAML was retrofitted to work on top of the web. For example, OIDC is also more suited for HTML5/JavaScript applications because it is
easier to implement on the client side than SAML. As tokens are in the JSON format,
they are easier to consume by JavaScript. You will also find several nice features that
make implementing security in your web applications easier. For example, check out the iframe trick that the specification uses to easily determine if a user is still logged in or not.
SAML has its uses though. As you see the OIDC specifications evolve you see they implement more and more features that
SAML has had for years. What we often see is that people pick SAML over OIDC because of the perception that it is more mature
and also because they already have existing applications that are secured by it.
SAML has its uses though. As you see the OIDC specifications evolve you see they implement more and more features that SAML has had for years. What we often see is that people pick SAML over OIDC because of the perception that it is more mature and also because they already have existing applications that are secured with it.