Currently I have an android app that uses the Firebase Auth for user Authentication. I would like to move the authentication part to the Admin Sdk server, such that The android app makes an http request to the server and the server does the authentication. Unfortunately the the Admin SDK for Java does not have the signInWithEmailAndPassword method. Is there a way to go about this or do I have to include the android sdk on the server also?
That's not a supported situation with Firebase Authentication. The client app must authenticate itself using the client SDK so that it can manage the ID token that lets the other SDKs work with respect to the security rules defined for those products (Realtime Database, Firestore, Storage).
You could call the Authentication APIs directly from the client, but it's far better to just let the client SDK do all that work for you.
Related
I'm developing an Android app working with a WCF service (through HTTPS). Everything is hosted locally and the app cannot be used for external network. For authentication, I implemented my own authentication system using internal username-password pairs, which is not highly secured.
I'd like my WCF service to be able to authenticate Android client app using AD accounts, ideally based on token. What do you recommend for WCF service and Android application?
I'm not expecting a full code, but some directions for both server-side (WCF) and client-side (Android app).
Thank you in advance for your suggestions.
PS: Looks like the introductions "Hi, good morning..." are automatically removed...
I recomend you to use "Client Certificate" to authenticate.
Basically your android app need to have "Client Certificate" generated by Certificate Authority - should be in your company if you have AD.
You may like this solution because you can use IIS Client Certificate Mapping - it's map your Client Certificate to your AD Account.
Disadvantages?
You need to provide to your phone "client certificate".
This can be achieved:
by the devices management system - e.q "Android for Work"
by mail :)
It's not easy - but certainly more safe than custom user/pass.
Android and Client Certificates
https://blogs.msdn.microsoft.com/asiatech/2016/08/22/how-to-create-an-iis-website-that-requires-client-certificate-using-self-signed-certificates/
First I build an AppEngine with java, that uses the Google Sign-In library:
https://cloud.google.com/appengine/docs/standard/java/users/
But now we want to also have an android app and switch from Google Sign-In to Firebase (because it integrates way better with android).
Unfortunately, I found no java sdk for firebase that would replace the Google Sign-In probably.
What is the best way, to add firebase authentication to a java AppEngine application?
Java has REST capabilities. Use Firebase Auth REST API.
i am looking at the ADAL for java project.
I understand the auth portion ok.
But i cannot find how to authorize the user against the ROLES in the AD.
what have i missed?
thanks
-lp
Azure AD doesn't have any good code samples for java web apps with OpenID Connect at this time. The best you can do is use a java OpenID Connect library (http://openid.net/developers/libraries/) and modify it to conform to Azure AD's protocol (https://azure.microsoft.com/en-us/documentation/articles/active-directory-protocols-openid-connect-code/).
The users roles will show up as claims in the id_token if you configure your app correctly. This sample shows how to do so in .NET: https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapp-roleclaims/
I'm developing a web application that has a REST api. At the moment the Api are protected in the server side trough spring security with a form-login authentication. Recently I also added spring social to allow access with facebook and twitter and all this works. So a user has to be registered to access some endpoint.
Now I have to build a mobile application that has to access the REST api and I was wondering what strategy I should use.
I saw that facebook has a android/ios sdk to allow the authentication on mobile side. So once theuser is authenticaded on the mobile I should do the request to my server so how should I authenticate the user on the server side to access the resources?
If you think that is not a good solution can you give me an advice how I should solve this problem?
Two options:
Your mobile app can login to your API the same way your other client code does, via form-login or spring social. Simply send the same session ID cookie with your API calls after login.
You can allow your app to accept a username and password as HTTP headers via HTTP-Basic, to save yourself the initial login step. This might be more useful if you don't need to make a lot of API calls per session.
I am trying to implement facebook SSO on my Android app. Once the user logs into the app using facebook he will make calls to my web service running on Google App Engine(GAE). Currently I am able to obtain the access_token from facebook on my android app. Then I add this access_token as a cookie to my http request to GAE . But I am not sure how would I authenticate the request from the user using the cookie, on GAE. Currently I am trying:-
User user = OAuthServiceFactory.getOAuthService().getCurrentUser();
String email = user.getEmail();
But my GAE web service is throwing this exception:-
org.restlet.resource.UniformResource doCatch: Exception or error caught in resource
com.google.appengine.api.oauth.InvalidOAuthParametersException
Is this the correct way of authenticating the user? If yes, then what am I missing here which is causing this exception.
Thank for the help!!
This is failing because you're not using OAuth. You're taking a Facebook connect authentication token - which also doesn't use OAuth - and attaching it to a request you're making to your App Engine app.
If you want to use OAuth with your app, you will need to authenticate to your App Engine app. If you want to reuse your Facebook credentials, you will have to use whatever API Facebook provides for verifying authentication tokens (if there is one), not the OAuth API.