Built-in OAuth support
Support OAuth to make it easy for mobile clients to securely talk directly to DocumentDB without a middle tier or a separate resource token broker.

Oath support to our data plane is currently not on our road map. We will review this request in our next review cycle and will update here on its status.
Thank you for your suggestion and votes.
11 comments
-
Thomas, Robert commented
Yes please
-
Benny Mathew commented
Yes please
-
Xiaoliang Zhang commented
Yes, please add support for Azure Ad b2c!
-
Jeremy Whiteley commented
Please add support for Azure Ad B2C
-
Atsushi Yokohama commented
Pleeeeease support this !
-
Samuel França commented
Yes, please support OAuth and OpenID Connect for DocumentDB, Thanks
-
Jeremy Whiteley commented
Please support this!
-
Alan Vance commented
Yes, please support OAuth and OpenID Connect for DocumentDB!
-
Anonymous commented
Great Idea
-
Rick Boardman commented
even using SQL Server I currently make CRUD style sprocs and in node.js basically pass-through the parameters to SQL Server. so in node.js I respond to route GET /api/some-collection by calling the sproc some_collection_get to return the full set. so the node.js really isn't needed.
all my sproc are run full access but I create a user context by boiler plating with the following:
-- refresh session and get security context
DECLARE @sesNow AS datetime, @sesIsValid AS bit, @sesIsGuest AS bit, @sesIsVisitor AS bit, @sesIsMember AS bit, @sesIsSomeRole1 AS bit, @sesIsSomeRole2 AS bit, @sesIsSomeRole3 AS bit, @sesAccountId AS uniqueidentifier, @accIsRestricted AS bit, @accIsApproved AS bit
EXEC [sp_SecurityContext] @sessionId, @sesNow OUTPUT, @sesIsValid OUTPUT, @sesIsGuest OUTPUT, @sesIsVisitor OUTPUT, @sesIsMember OUTPUT, @sesIsSomeRole1 OUTPUT, @sesIsSomeRole2 OUTPUT, @sesIsSomeRole3 OUTPUT, @sesAccountId OUTPUT, @accIsRestricted OUTPUT, @accIsApproved OUTPUTobviously it needs work as the "in roles" should be an array but you get the idea
With that I can tailor the logic and the returned view
-
Rick Boardman commented
If you provided a public access restAPI endpoint (that doesn't require the master key) that could take an email address and password and return a token (similar to permission token).. maybe call it authToken
and the ability to expose stored procedures via rest GET (actually all rest CRUD would be nice) sending the authToken in the headers and make that authToken available in the context of the sproc
then we can create single page applications purely in client side javascript without exposing a master key, without the need for a middle tier. inside the sprocs we could check the auth token against the users, verify specific security, return views specific to the role.
it would also be nice if that authentication process allowed 3rd party authentication and simply stored the 3rd party token. if not then ok we can make a little middle tier simply to handle 3rd party and assign the token ourselves.
you are so close to providing a true rest CRUD database accessible by a purely client single page application.