In my last post, we walked through some real-world systems that map roughly to the OAuth framework. In this article, we will discuss the key terms that go along with the framework.
I’ll be honest with you, I love big words, but I can’t always remember big words. So in this post, we’ll look at the big words that OAuth uses most frequently and try to break each one down into smaller, more memorable pieces.
To start, we have the Resource Owner, which is often thought of as just “the user”, but is actually the person or machine who should be able to access… something
That “something” is a Protected Resource, which is just a fancy way to refer to that thing-i-only-want-certain-people-to-touch. To put it in context, this might be the photo album in your social media account that you want to upload embarrassing karaoke pictures into.
This brings us to the Relying Party, which is NOT the most boring party ever, but is instead the party or application that must rely on another source for authentication. This might be the social media platform that needs some other source to confirm that the user is allowed to access those prized karaoke pictures.
That “other source” that the Relying Party uses to determine users’ authorization is called the Authorization Server. This term tends to get muddied the most, and can be called a range of things like “Authorization Provider” or “OIDC Provider”. I personally prefer the term “Authorization Provider” because this actor provides authorization as a service, and is not necessarily a free-standing “server”. The Authorization Provider will usually be a third party source like Google or Beyond Identity, that provides authentication as a service so that your users can log in.
Once the user is authenticated, the Relying Party is able to retrieve one or more Tokens which provide critical information. There are two key tokens that you need to be aware of, and those are the Access Token and the ID Token. The ID Token is optional and may be requested in various ways. It is intended specifically to be used by the client-facing portion of the Relying Party to identify aspects about the User. The Access Token is intended to be used by the server-facing side of the Relying Party, and should never be visible to the client. It is used to provide authenticated access to upstream servers or services - like that photo album service, so you can delete those karaoke pictures before it’s too late. Seriously. Go delete those pictures.
Top comments (0)