Home/ Questions/Q 4345626
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T12:03:40+00:00

After a real brain bending session today I feel like I understand 3-legged OAuth

  • 0

After a real brain bending session today I feel like I understand 3-legged OAuth authentication fairly well. What I’m still having trouble understanding is the use of the User ID. The examples I have seen so far all seem to just arbitrarily assign a user ID at the top of the sample script and go. That confuses me.

Most of the sample code I have seen seems to center around the concept of using a user ID and the OAuth server’s consumer key for managing an OAuth “session” (in quotes because I’m not trying to conflate the term with a browser “session”). For example, the database sample code I’ve seen stores and retrieves the tokens and other information involved based on the user ID and consumer key field values.

I am now in that state of uncertainty where a few competing fragments of understanding are competing and conflicting:

1) If my understanding of the OAuth session details record or “OAuth store” lookups is correct, via the consumer key and user ID fields, then doesn’t that mandate that I have a disparate user ID for each user using my application that connects with an OAuth server?

2) If #1 is correct, then how do I avoid having to create my own user accounts for different users, something I am trying to avoid? I am trying to write software that acts as a front end for an OAuth enabled service, so I don’t need to have my own user records and the concomitant maintenance headaches. Instead I’ll just let the OAuth server handle that end of the puzzle. However, it seems to follow that the downside of my approach would be that I’d have to reauthorize the user every session, since without my own persistent user account/ID I could not lookup a previously granted “good to revoked” access token, correct?

3) What bothers me is that I have read about some OAuth servers not permitting the passing of a dynamically specified callback URL during the requesting of the unauthorized token, making the passing of a consumer key and a user ID back to yourself impossible. Instead you specify the callback URL when you register as a developer/consumer and that’s that. Fortunately the OAuth server I’m dealing with does allow that feature, but still, if I was dealing with one that wasn’t, wouldn’t that throw a giant monkey wrench into the whole idea of using the consumer key and user id pair to index the OAuth session details?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I will try to tell my view on the issues that you raised and hope that will clear things a little bit…

    First, the idea is that the OAuth server is protecting some API or DATA, which third party applications (consumers) want to access.

    If you do not have user accounts or data at your API behind the OAuth server, then why would a consumer application want to use your service – what is it going to get from you? That being said, I can’t imagine a scenario, where you have an OAuth server and you don’t have user accounts behind it.

    If you just want to use OAuth for login of users, without providing user data through API, then it’s better to use OpenID, but again you will have to have user accounts at your side.

    Your point is correct that you make lookups via Consumer Key and (Your) User ID, and that is because of the protocol design.

    The general flow is:

    1. OAuth server (Provider) issues unauthorized Request Token to consumer application
    2. Consumer sends the end-user to authorize the Request Token at the OAuth server (Provider)
    3. After end-user authorizes the token, an access token is issued and given to the consumer (I’ve skipped some details and steps here, as they are not important for what I want to say, e.g. the consumer receives valid access token at the end)
    4. On the authorization step, it’s your OAuth server that create and save as a pair – which local user (local for the provider) authorized which consumer (consumer key-user id pair).
    5. After that, when the consumer application want to access end-users DATA or API from Provider, it just sends the access token, but no user details.
    6. The OAuth server (Provider) then, can check by the token, which is the local USER ID that has authorized that token before that, in order to return user data or API functionallity for that user to the consumer.

    I don’t think that you can go without local users at your side, if you are a provider.

    About the callback question, I think there’s no difference if you have dynamic or static (on registration) callback URL in regard to how you handle OAuth sessions with consumer keys and user id. The OAuth specification itself, does not mandate to have a callback URL at all – it’s an optional parameter to have, optional to send every time, or optional to register it only once in the beginning. The OAuth providers decide which option is best for them to use, and that’s why there are different implementations.

    When the provider has a static defined callback URL in the database, connected with a consumer, it is considered a more secure approach, because the end-user cannot be redirected to a ‘false’ callback URL.

    For example, if an evil man steals the consumer key of a GreatApp, then he can make himself a consumer EvilApp that can impersonate the original GreatApp and send requests to the OAuth server as it was the original. However, if the OAuth server only allows static (predefined) callback URL, the requests of the EvilApp will always end at the GreatApp callback URL, and the EvilApp will not be able to get Access Token.

    • 0