Last time, we learned that OAuth lets you share resources with applications safely by giving out a token instead of your password. If I want a game I'm playing to post my score on my Facebook wall, I give the game a token saying it can -- I don't give it my Facebook password.
The whole point in OAuth, no matter what use case you have, is for a third party client application to get a token to access your resources.
So, when we say "token" we're simplifying it a bit. There are actually different tokens the authorization server can hand out.
Wait! That's a new term. What's an authorization server?
An authorization server hands out tokens. But now we know that there are different kinds of tokens. So when we've been saying "token" what we've meant is "access token." It's very aptly named -- it grants access.
Imagine that you're a contractor. On your first day of work, you can't just walk into the building -- you have to go to the security office and get a badge. The security office is an authorization server that issues badges. And those badges are effectively access tokens. They let you into the building.
So maybe I have a web application called Tunes Partner that sells songs and I want to buy a song off it using my bank account. Tunes Partner needs to charge my bank account $10, so I tell the bank's authorization server, "Give Tunes Partner an access token saying it can charge me $10." Tunes Partner can use that access token to charge me, and I get my song. I never give Tunes Partner my bank password, so it's far more secure (if you'd like more elaboration on that example, see my previous article: Susi's awesome OAuth intro).
If you want to learn more, you can take a free online class on our training center or wait for my next entry!
Susi Remondi is a Technical Content Creator and Instructor at Ping Identity.