I'm using couchbase lite in an android app with sync gateway and couchbase in the server and it works great.
Now I want to make a request to node.js from the android app, and i want to use the same session to authorize the user in the node.js app.
Is it possible?
Can I read the session in node and match it with couchbase?
You're asking about authorization. This is tied to authentication, but you should make sure to distinguish between the two. It sounds like what you want is to authenticate the user, then have your node piece authorize access based on this.
Having said that, it depends some on the type of authentication you're using to establish your session.
Basic Authentication (when used directly with Sync Gateway) just passes a username and password that gets checked. I think you get a session cookie after that. It would be very difficult to use that to authenticate to anything else (as in, you'd have to modify Sync Gateway code yourself).
OpenID Connect, in the auth flow, might give a few ways to possibly do this.
One simpler way is to have the node app also authenticate the user. If this flowed through the same browser, the browser will often keep state that would allow the user to bypass re-authenticating. This could be a little clunky, because you'd have to pass things off to a browser (or a webview, but there are security issues with that, too), which the user would likely notice.
Another approach would be to be to do a sort of double redirect. (I think this would work, but I haven't tried it. I can't find documentation on whether an authorization code can be used twice.) In the authorization flow, have the redirect go to the node app. Then have the node app redirect again to Sync Gateway. Both apps can ask for the ID token.
Yet another way would be to have your Android app ask for the ID token directly and pass this in some protected way to your node app. As always, you'd have to protect against replay attacks, and I'm not sure what else, so this could be challenging.
In any case, Sync Gateway is built to request the ID token itself, so any approach will need to ask for the ID token twice.
Here are some references you can look at to investigate this further yourself.
http://connect2id.com/learn/openid-connect - A nice write-up of the OpenID Connect protocol.
https://developers.google.com/identity/protocols/CrossClientAuth - Google Identity Provider documentation that addresses sharing authorization between a mobile app and a web app.
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html - A post describing the distinction between authentication and authorization, and why OpenID Connect (not OAuth) should be used when needing authentication.
Note: You can't use the Couchbase Node.js SDK on the bucket that is used by Sync Gateway otherwise it will mess up with the _sync metadata and documents won't sync properly; but you can query documents, create sessions, etc. using the Sync Gateway REST API.
You can refer to the documentation of the Sync Gateway REST API to get the list of available endpoints. And if you don't want to roll out your own HTTP wrapper, a JS library is available that runs on Node.js and in the browser: http://developer.couchbase.com/documentation/mobile/1.3/develop/guides/sync-gateway/rest-api-client/index.html.
Related
I'm developing an Android app. I have used firebase(email, password) authentication mechanism which is very secure and easy to implement. And as I want the data to be stored in our servers, I'm not using firebase storage. Couchbase sync gateway supports any open ID authentication. But I'm finding difficult integrating both. I have been searching more than a week. Anyone who have already used it. Could you please help me configuring.
For anyone looking for an answer, here are the steps to do it:
Firebase sends you an id_token (not signed). I assume you got to this part.
You convert this unsigned firebase id_token to a signed 3rd party oidc id_token. I use Keycloak running lightweight in a docker container for this job. Remember, you want the id_token, not access_token.
(Optional) you use Sync Gateway (SGW) ADMIN REST end point to create an user and assign the user to his/her appropriate [admin_channels].
SGW will accept your Keycloak signed oidc and give you a cookie when you hit its REST interface at the /_session end point. Make sure you put the id_token string in the Authorization header in the format "Bearer id_token_string........".
A few notes:
SGW will use the username (or create a new one if none existed) based on the "username_claim" keyword definition in your SGW.json config file. Use Keycloak client's mappers function if you want to customize your SGW user's name.
If you want to get the user's id_token without having to know the user's password then use the experimental token-exchange feature as mentioned here. enter link description here.
You use this cookie information to connect and sync data with couchbase via SGW as usual.
Couchbase has an article on how to implement implicit flow for oidc using syncgateway source
I'm currently designing a service that will be half web app, half android app. Each user will need to be able to log in from either the android app or the web app, using an openID account. I'm hoping to target Google first for easiest integration with Android, but I'll also need some OAuth stuff later so that I can integrate with Google contacts.
The bit I'm having trouble with is how to authenticate users. The structure I've planned is that the server (probably using web.py, although that's flexible right now) serves data for the client in JSON, whether the client is the javascript browser client or the android client. However, each call needs to make sure the client is allowed access to that data.
What would be the easiest way to standardise this across the platforms?
Should I be using a session system to authenticate after logging in? Can that be made to work from an Android app? Otherwise, should I simply authenticate with google for every request?
When authenticating from the app, where should the authentication happen, through the server or straight from the app? Where should the auth token be stored in this case? (I'm assuming for a straight webapp the token should just be stored in a table in the user database?)
Sorry for the barrage of questions, but I haven't really found any resources online that clarify these issues very well.
As long as you are using HTTP, the platform doesn't matter. You can use the same form of authentication and/or sessions. The only difference would be that on Andorid you might be able to get an authentication token using the platform's AccountManager, without having to type the username and password in Google's login page.
There's a subtle difference between Authorization (OAuth) and Authentication (OpenId). Make sure you know what you are doing.
New to OAuth2. I am writing an Android app that communicates with an App engine server application.
The app needs to authenticate itself with the server on behalf of the user, using Google account info of the user. The server needs to retrieve the user's basic info and create an account . That's the easy part and I know how to do this.
Furthermore, the Android app will also have the user authenticate himself/herself using Oauth2 and retrieve basic user info using Google account info of the user. I can do this as well.
This is where I need help Assuming the previous steps have been completed successfully, how can I use the Android app (where the user has logged in) to communicate with the server securely using the user's credentials.
Any ideas or am I missing something obvious?
The Android to App Engine OAuth2 communication is documented in this answer:
google app engine oauth2 provider
Using OAuth, 1.0 or 2.0, doesn’t matter in this, leads to the app obtaining an access token - then based on the API of your server, you pass this access token with requests instead of login and password. I guess the way to attach the access token string to URL requests may be slightly different between different APIs, see the documentation for yourself. Or if you are making the server app at the same time, then you need to figure out your way to do so (like sending a HTTP header Authorization: OAuth access_token=abcdefgh….
I'm developing an android app that consumes a webservice that I will develop too (I'm thinking in using a RESTFul webservice)..
and I want to secure the connection between the app and the server but I need to authenticate users too..
My problem is in the last part, to secure the connection I think the best way to do it is to use SSL (https), am I wrong?
I don't know what's "the best way" to authenticate users, to make sure that a user cannot consume the webservice as another user..
I have some ideas, like using a authenticate(login,pass) method on the webservice that returns a token.. And for any operation that requires authentication the user would need to pass that token as a parameter.. The thing is, is this a good way to do this? whats the most common technique used to auth users in a situation like this?
If a token based auth is a good idea how should I generate the token?
Sorry for this long text..
Any help will be usefull
Thanks
Make sure you understand a trendy standard like OAuth before you go down that path. Most OAuth flows are centered around a user logging in to your server through a web browser. This can lead to pretty bad user experience for a mobile app. The standard does allow for alternatives. Here's a decent introduction.
You could also use an existing identity provider like Google, Facebook, Twitter, etc. instead of implementing your own authN/authZ. On Android, you can ask for a Google auth token using the AccountManager. This usually works because the user needs to be logged in to their Google account to access the Android Market. Anyway, this will prompt the user to grant authorization to your app. You could then use the Google auth token to login your user to your service with your own token. The login would essentially be your server verifying the Google token is valid (by contacting Google's servers) and then issuing its own token to be used for calls to your web services. If you don't like Google, you could use the Facebook SDK, etc.
As for what to use for tokens... The OAuth spec has stuff on that as well. You could do something as simple as a random string or something as complex as encrypted SAML assertions.
You should implement a token based OAuth, which will require the users to log in once, and then permanently have access.
You can use Google App Engine which already provides user authentication services for you (your Android users most likely already have google accounts) But this is only one of many options.
You can also look into Amazon's Identity Access Management (IAM) which will allow you to manage the users who have access to your web service, and authorize them accordingly.
I think the best way to do it is to use SSL (https), am I wrong?
This only prevents certain types of malicious use, but not everything. There is still nothing to prevent people from accessing your database on the phone, and retrieving credentials that way.
I am in the planning phase a new project. I want to be able to control multiple relays from my android powered phone over the internet. I need to use an HTTP based server as a middleman between the phone and the relays. Django is my preferred platform because Python is my strongest skill set. This would not be a "web app" (with the exception of the admin interface for managing the user and their access to the relays). Rather, the server would simply provide an API in the form of HTTPS requests and JSON encoding. Though, I should note that I have never done any web development in my life, so I don't know best practices (yet). The authentication method should meet the following criteria:
Works over HTTPS (self-signed SSL)
Provides multi-factor authentication (in the form of something you have and something you know)
Be reasonably secure (Would be very difficult to fool, guess at. or otherwise bypass)
Is simple in implementation for the server operator and end user on the mobile client
Is lightweight in in terms of both CPU cycles and bandwidth
I plan to use the following scheme to solve this:
An administrator logs into the web interface, creates a user, and sets up his/her permissions (including a username and a password chosen by the user).
The user starts the client, selects add server, and enters the server URL and his/her credentials.
The client attempts to authenticate the the user via HTTP auth
(over SSL). If the authentication was successful, the server will generate an API key in the form of a UUID and sends it to the client. The client will save this key and use it in all API calls over HTTPS. HTTP auth is only used for the initial authentication process prior to reviving a key, as a session scheme would not be nessessary for this application. Right? The client will only work if the phone is configured to automatically lock with a PIN or pattern after a short timeout. The server will only allow one key to be generated per user, unless an administrator resets the key. Hence, simple, mobile, multifactor authentication.
Is this sound from a security standpoint? Also, can anyone point me to an example of how to use the HTTP auth that is built into Django? From a Google search, I can find a lot of snipits witch hack the feature together. But, none of them implement HTTP auth in the wayit was added to Django in 1.1. The official documentation for REMOTE_AUTH can be found here, but I am having difficulty understanding the documentation as I am very new to Django.
I'm not entirely sure of how basic auth would work on Django, but I can take a shot.
The basic auth article on wikipedia covers a pretty standard usecase for logging in. For Android I've personally skipped the first part (401) and just pass my credentials in right away.
With your auth request you will have to just grab the user credentials from the request headers (WWW-Authenticate) and then do all the necessary work for that. With the credentials you can then just use the authentication framework provided in Django to verify that the user then generate their UUID (I guess).
As for basic auth on Android it's a little bit tricky at first and may leave you pulling your hair. I've found this article on Basic HTTP auth for android which helps explain how to do it.
As for the security part of it, I'm not too sure. It's pretty simple, which I'd say is a good thing :)