Our system has users but we want to perhaps allow some users to be able to use our API service. I'm looking at using OAuth2 for authorization. As it's going to be (trusted) machine-to-machine access I also thought to use client credentials.

So, for example, when we create an article through our API we want it to have an author (user). So perhaps store access tokens, auth tokens, client credentials in the users collection for each user that is granted API access? Is this good practice?

Users collection:

        "_id": MongoId("uguifdguioei..."),
        "username": "joe.sixpack",
        "oauth": {
            "client_id": "1234567890",
            "client_secret": "qwertyuiop1234567890",
            "access_token": "8sf989dgd9fgdjkngf77y3retr8ghujker",
            "refresh_token": "usknfgeor..."

In another (MySQL) project I have a bunch of additional tables (oauth_clients, oauth_scopes, oauth_access_tokens", etc) but I would rather avoid creating a bunch of new collections. Also, perhaps with mongo I can take advantage of nested data.

Also, attaching the oauth stuff to the user would mean we could perhaps rely upon our apps ACL for authorization (rather than scopes) and use the oauth storage for simply issueing and verifying auth codes, access tokens, refresh tokens etc.

I haven't started on development yet, just trying to figure out a clean way to handle the Oauth stuff. Would appreciate any feedback on this implementation, thanks

1 Answer 1


1) You should always encrypt the sensitive info. From your example the secrets will be in plain text

2) I would not mic the user table with the secrets. Imagine you are reading user data into the user object,then somebody adds a log line that logs the entire object => plain text secrets in logs. Handling them separately would be much better

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.