Sorry .... I want to completely rephrase this question:, and I've asked the same question on Information Security now
The system I'm working on will have a mobile application, a web portal and an HTTP-based API.
The question that I cannot seem to find an answer to:
Do I need to implement the openid connect and/or oauth token endpoints and generate tokens for the client to access my API? Or do I "somehow" enable the client(s) to access the API using tokens issued by the user's open-ID provider?
More background:
I want to allow users to be able to register and log in using their Google / Facebook IDs.
Within the API I store a user table with some attributes, minimal because I don't need more than this, but essentially:
Table users:
- uid
- real_name
- contact_number
- email_address
- is_active
- have_admin_rights
I would also set up a table for the users' open-ids, like this:
Table open_ids:
- uid
- user_id (References users(uid)
- open_id
(so that a user can use any of their Open-IDs that they want to associate with their account)
Elsewhere I reference the user id, eg:
Table foo:
- uid
- bar
- bla
- last_modified_by_user_id (References users(uid))
Currently, in my test setup, I have a "passwords" table, eg:
Table passwords:
- uid
- user_id (References users(uid))
- password_hash
(Note: The idea is to get rid of this table soon and use open_id in stead. But which libraries I choose very much depends on what functionality I implement and what I use from external sources)
I gather that I need to store the access tokens since I would prefer not to duplicate user data which is already in their social service profiles, and need to access those services for each user from time to time. But how do I get the access token from the Client (where the user signed up) to the API (which is the shared resource between the various clients)
The problem isn't really sending the token from the client to the API so much - I can just have a function in the API to "register" a user and some other endpoints for when a user is being authenticated. The problem is that an access token is meant for one specific client only.
Assuming I do NOT implement an authorization server and somehow can use the services from google, etc: On the Developer sites, eg for google, facebook, I can register my client and be issued the client secret/client id, but do I then use the same client credentials from BOTH the Client AND the API?
Or maybe the client credentials only gets kept by the API, and the front-end service depends on the API as an intermediary step when a user registers? This feels horribly dangerous to being insecure. So is the API another separate client in the eyes of the OpenID provider?
Assuming that I do need to implement an authorization server, do I need to also be an open-id provider? It seems in this case it would have to be openid-connect because I do need to have both authentication AND authorization. But in this case I'm really lost in terms of how to perform new user registration, and the previous questions doesn't really go away. It would seem that I should be able to let the client connect and get the user authentication / access and ID tokens from the Open IdP and then "register" the user with the API.
