If you are running the so called second database, I think using OAuth 2.0 is superfluous. If the second database is an outer to your system, and in fact you communicate with that DB via an API (as you said), then you can use OAuth 2.0. Also, it depends on the way "the second DB" checks a given information is requested by an appropriate user (simply put I suppose user A cannot access user B personal information stored in the DB). In short, OAuth 2.0 is not a silver bullet and whether it's an appropriate solution or not depends on the case.
On Friday, April 25, 2014 9:00:14 AM UTC+3, Danny Haberer wrote: > > Hi All, > > I have a general question wether I should use OAuth2 or not and I hope > someone is able to help us make the correct decision. > > This is my situation: > We have clients login to our website. From that login they can request > (personal) information which comes from a second database. This is > (ofcourse) API based. > > Only clients from our website are allowed access to the second database. > Is OAuth 2 the best method for this or should we use an unique string as > key and have this as verification (unique string can be a combination of > unique client information; encrypted). > > As I understand OAuth2 now it's primairly used for users that want to > grant access to multiple applications to use data from their personal > account on, ie. Facebook. > Since we already "know" the clients username and password (although it's > stored encrypted) I believe we can do without OAuth. > > I'm looking forward to your suggestions and ideas. > > Best regards, > > Danny > -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to oauth+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
