an open ID connect. We have to call the service provider a relying party
instead of an I D provider there. An open eyed provider. Really, Those are the big differences. Same basic idea.
The way open ID Connect works natively 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 services, I'm going to connect based on how I attempt to connect Kelly Hanrahan at abc dot 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 open eyed provider and says, Is this person legit? Can we trust them?
The open eyed provider sends back to an open ID token that provides that authentication.
Then, ultimately, the relying party is going to be able to provide the services to the end user clients.
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 Open I D party, just like it was between the S. A. M. l service provider and the S A. M L I D provider.
It's all about this trusting relationship.
The big benefit is the user logs on to their identity provider and they're not sending authentication information across the Internet.
No username and passwords go across the network just the S A M L tokens that would not be valuable in any way to an attacker. Single sign on where their identity provider, our identity provider, uses tokens to vouch for their authenticity.
This is the direction that we're going out on the Web.
One other element that's part of open ID Connect is called O Oth. We're on a path to this is just simply a framework. It isn't a specific protocol or a type of a P I.
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. C s Facebook is actually my identity provider?
Facebook is sending me a token on behalf of the Spotify to validate my identity and to authenticate me.
Usually I get a little message that pops seven says, Would you like Spotify to update your Facebook page so your friends can know what 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 sorts of financial information.
Of course, you have to give it permission to do so.
That's so, uh, that's the ability to act on my behalf in order to increase usability and inter probability,
it winds up being very valuable, and this is a framework on which we're designing applications.
The whole goal here for a single sign on and Federated Trust is to take some of these ideas, and we just take for granted in a local domain. I just take for granted. I log on to the domain and then I can print to my printer access to database or whatever I need.
What we're doing with S A. M L and Open ID 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 their 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.