0

When I read and watch videos on Oath it talks more about being able to access data from other applications. However, a common usage of what I think is OAuth is simply identifying a user without requiring them to have a id/pw for a site. I don't see that explained very often though. What is the concept behind that process?

Say there is a forum website that lets you sign in via your google account. All it gets is your first and last name and you never have to create a pw for that site specifically because they go through the google OAuth process to ID you. How does that process work? Is that site storing some token on their db? Is that token specific to the user and your site and never changes so that each time they login via google to your site you can just validate the stored token in your sites DB vs the one google gave them?

Improve this question
11
  • I don't see that explained very often though. What is the concept behind that process? Ask for a ID token to the 3rd party service, so that your application can assert that you are who you are saying to be, just by sending the same ID Token to the 3rd party service an ask for confirmation.
    – Laiv
    Commented Mar 2, 2018 at 14:51
  • 1
    You are missing one of the first steps of OAuth2, the 3rd party service ask you for a user and password. Don't they? That's your authentication. Your server will validate the ID Token and will gather all the info it needs from the 3rd party service for authorize to you to pass. That's your authorization. That's why OAuth is all about authorization and not about authentication
    – Laiv
    Commented Mar 2, 2018 at 14:54
  • @Laiv What does it mean to "validate" the ID token? I mean my site is just getting back a token right? That token could come from anywhere. What constitutes validating the token? Is that token always the same for that person and my web app so that I can say this is x person in my database because I would have gotten the token on registration for this use and I stored it along with their name in my users table?
    – user441521
    Commented Mar 2, 2018 at 15:10
  • I mean my site is just getting back a token right? Right, the one the 3rd party gave to your client. What constitutes validating the token? send it back to the 3rd party service (who generate it) from your site (usually the server-side). Is that token always the same for that person They also expire. Some OAuth servers also give you back a refresh token. I would have gotten the token on registration for this use and I stored it along with their name in my user's table? You could, that's fairly common.
    – Laiv
    Commented Mar 2, 2018 at 15:26
  • @Laiv "You could, that's fairly common" That's the part I'm referring to where I don't find many details about that usage. It's all about getting information from said app to use in another app, which this isn't really part of that exactly. It's really just being used so a site doesn't need to store and manage user passwords, which is the part I'm mostly interested in but have trouble finding that usage.
    – user441521
    Commented Mar 2, 2018 at 17:35

1 Answer 1

Reset to default
1

OAuth is mainly about authorization delegation. i.e. you as a user, delegate the privileges to perform some operations on a resource that is owned by you, on behalf of you.

For instance, consider the use case, where you as the owner of the bank account (resource owner) have a financial consultant (Client) to manage your bank account (Bank being the resource server). There are 4 things in here:

  1. Bank (Resource Server) and the financial consultant should have a trust relationship whereby financial consultant has a specific clientID and secret with privileges scoped to perform certain activities on behalf of a user.
  2. When the financial consultant (client) tries to perform a specific operation on behalf of you, the resource server or a authorization server that the bank relies on will throw a login screen to you. Once you login, it should ask for your consent to allow the financial consultant to perform the operation for you.
  3. Based on your consent, the financial consultant is issued a token. In general it is a short lived to token (valid for 15 min - 1 hour) depending on the use case. The token will contain enough information indicating that the operation can be done only on your account.
  4. Now the Financial consultant can use this token to perform those authorized operations on your bank account, on your behalf without concerning you with the need to authorize each individual action.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.