diff --git a/securing_apps/topics/overview/supported-protocols.adoc b/securing_apps/topics/overview/supported-protocols.adoc
index 285284c8e2..0d24553434 100644
--- a/securing_apps/topics/overview/supported-protocols.adoc
+++ b/securing_apps/topics/overview/supported-protocols.adoc
@@ -50,7 +50,7 @@ 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 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.
+make implementing security in your web applications easier. For example, check out the link:http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[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 with it.
 
diff --git a/server_admin/topics/sso-protocols/saml-vs-oidc.adoc b/server_admin/topics/sso-protocols/saml-vs-oidc.adoc
index 0f97920472..77b42230a0 100644
--- a/server_admin/topics/sso-protocols/saml-vs-oidc.adoc
+++ b/server_admin/topics/sso-protocols/saml-vs-oidc.adoc
@@ -10,6 +10,6 @@ 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 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.
+make implementing security in your web applications easier. For example, check out the link:http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[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 with it.
\ No newline at end of file