>> In OpenID Connect, we have to call
the service provider, a relying party.
Instead of an ID provider,
they are an OpenID provider.
Really, those are the big differences, same basic idea.
The way OpenID Connect works [inaudible] is it
takes a little bit of the weight off
>> the client browser.
>> For instance, I'm going to
try to connect to an organization,
whatever that service is,
I'm going to connect.
Based on how I attempt to connect,
kellyhand.hand@abc.com, that relying party
knows who my identity provider is.
Again, that's set up by the administrator.
Instead of redirecting the client's browser,
the relying party challenges
the OpenID provider and says,
is this person legit, can we trust them?
The OpenID provider sends back to
an OpenID token that provides that authentication.
Then ultimately, the relying party is going to
be able to provide the services to the end-user client.
We still have that back and forth step-by-step process,
but ultimately, it's about
the trust relationship between the relying provider,
or the relying party and the OpenID party,
just like it was between the SAML service provider,
and the SAML ID provider.
It's all about this trusting relationship.
The big benefit is the user logs onto
their identity provider and they're not
sending authentication information across the Internet.
No username and passwords go across the network,
just the SAML tokens that would not
be valuable in any way to an attacker.
Single-sign-on where their identity provider
uses tokens to vouch for authenticity.
This is the direction that we're going out on the web.
One other element that's part of
OpenID Connect is called OAuth.
We're on OAuth Two. This is just simply a framework.
It isn't a specific protocol or a type of API.
It's a framework that we designed our applications on,
so you can delegate rights or
actions to specific applications.
For instance, let's say that I
want to go to Spotify and listen to music,
and asks me, would you like to use
your Facebook account to login?
If I say yes, Facebook is actually
>> my identity provider.
>> Facebook is sending me a token on behalf
of Spotify to validate my identity,
and to authenticate me.
Usually, I get a little message that pops up and says,
would you like Spotify to update your Facebook page so
your friends can know it music you're listening to?
When I click "Yes",
that's giving an application the right
to modify another application,
and the right to modify Facebook is only mine.
I'm the owner of the Facebook page.
I'm the only one who's allowed to update the page.
I've just delegated that right for
Spotify to do something on my behalf.
Same idea, if I'm doing
accounting and I log into QuickBooks,
one of the features of QuickBooks is they can pull
your credit card information
from your credit card companies,
they can pull your bank statements,
they can pull all financial information.
Of course, you have to give it permission
to do so. That's OAuth.
That's the ability to act on my behalf in order to
increase usability and interoperability.
It winds up being very valuable.
This is a framework on
which we're designing applications.
The whole goal here for single
sign-on and federated trust is to
take some of these ideas that we
just take for granted in a local domain.
I just take for granted,
I log on to the domain,
and then it can print to my printer,
access a database, or whatever I need.
What we're doing with SAML and
>> OpenID Connect is they're
>> both serving the same purpose of
logging onto identity provider.
As long as our administrator sets up
the proper federated trust,
we can log in once to that identity provider,
and then access all the resources that
has trust, whether they're local,
or in another organization,
or anywhere across the world,
as long as the trust has been set up.
It is going to expedite administration
>> and make it easier
>> for admins to have tighter control of
what users access what resources.
It's also going to make life much easier on users,
because they won't need to keep up
with so many passwords.