We have a Phonegap app (Android and iOS) and web app with web API that need to use Google plus authorization. We can't figure out how to implement that. So far we only accomplished to obtain access token from mobile app and send it to server, but that's not how it's supposed to be done for several reasons.
What we are trying to accomplish is to obtain authorization code from mobile app, send it to web component and get access token and refresh token there, which is the right way, and that's how it's done using native iOS and Android SDK, but for some reason it either can't be done using Phonegap, or we just can't figure it out. For web app it woks normally. If someone has experience with this that would be very useful.
The important thing is that user can log in from different devices and that API can recognise him and use refresh token to authorize.
It would also be nice if we could use the same app id for all clients.
Related
Please forgive my (perhaps naive) question, I am still a beginner!
I have a website on asp.net core that is essentially a CRUD website. There are some Razor pages and some controllers. When the user is logged in, they can create and update the data they own (through javascript and said controllers).
Login is organised via Cognito's built-in UI. I redirect the user to it with the [Authorize] attribute on certain controller actions. The token (I think this is what it's called?) coming from Cognito is automatically stored in the browser cookie and is passed between the browser and the backend (controllers and Razor pages). In the backend controllers and Razor pages, I have very convenient methods like User.IsAuthenticated(), and can get claims and fetch cognito:username and similar fields.
The website is working well enough.
I am now working on native mobile apps (Android and iOS), and I am wondering how to deal with authorisation in them as well. I want the user to have the same experience in the mobile app as on the website: they would log into the mobile app and see and edit the data they created earlier on the website, and vice versa. I'm not sure how to implement this correctly. I see several options:
Option 1. Use the AWS amplify framework in the apps. I am sure it will work nicely; but how will I then pass the token to my backend controllers? Asp.net core needs it to build this User object, I understand. I think asp.net core stores it in the cookie appropriately named .AspNetCore.Cookies, but I'm not sure as to its format and whether it'll stay stable in the next releases?..
I'm currently reading about JWT bearer tokens, maybe that's the thing that should be used instead of .AspNetCore.Cookies?..
Option 2. I could "pretend" that the mobile app is the same as the browser and send exactly the same requests as my web frontend does. I suppose this sounds very complex - I'd need to store cookies, follow redirects (to the cognito built-in ui, for example) - I don't know if there is a built-in mechanism? However, in this case the app doesn't have anything to do with cognito, talks only with my backend, and is just following redirects. AppAuth states that Authorizing the user occurs via the user's web browser, so perhaps it can be used here?
Perhaps there are other options that I overlooked; I'm almost sure there is a simple solution I just can't see at the moment. Sorry it's all over the place, this is a very new topic for me. Thank you in advance!
I have a project, angularjs webapp (backend java and spring boot) and uses google map too, there is an android app that sends alerts to this webapp and those show location on the webapp’s map. However when I implement spring security it would secure the webapp and REST api, but will prevent the alerts from android showing on the map (can not find resource)….
I want an easy simple way to secure the app without stopping the REST API services, yes I want to secure my API but still want to be able to show the alerts sent from android device, also still accepts new registration from android users....(android users cant access webapp they only register to use android app and will be added to database..they will need to be able to post their info...)
I tried oauth2 using google sing in, but I must be missing something as it wont load,..If you think this is the right approach please confirm...I will further look into it...Or direct me to tutorial or give me any suggestions...
P.S I am using bluemix platform as a service at the moment and CLearDB database service from bluemix
I am a student and all this is new to me...Thanks
I have a web based service (running for years) that works with google apis.
Now I would like to create an android and iphone ui (using xamarin) that uses my web services which in turn talks to google apis.
Given that I don't talk directly to google apis from the phone, do I need to use a web browser control to let the user login, or can I authenticate my server and establish a session natively on the phone?
I'm afraid I need to use a browser window, and I don't think it's user friendly to have to login to a google account in a browser window on the phone.
(I want to keep the logic on the server, so that the phone apps and the web ui uses the exact same code for it's calculations.)
EDIT: It seems Cross-client identity is what I'm looking for.
It can be done natively. See this video https://www.youtube.com/watch?v=9wAx39s10yw which explains all of the procedure using cross-platform authentication.
I'm building a mashup app for Android Wear, using speech recognition so I can post to Fitbit's API. Single-purpose and pretty simple. I generated the OAuth 1.0 credentials with the excellent Temboo library and granted access in a desktop browser, then naively hard-coded those keys and tokens into my app and let Temboo take care of the HTTP requests and API calls to Fitbit.
I've gotten errors from Fitbit stating that my requests are being refused by Temboo's server because of invalid OAuth signature (Fitbit uses OAuth 1.0). I've come to the realization that I probably need to have the user grant access on the wearable app itself. I'll need to launch the mobile browser and pass it the authorization URL from Temboo in a WebView, then have the user grant access, and then pass this approved data back to the watch.
Is there a pattern for doing this in order to allow access to third-party web service APIs already? I've not seen documentation on it so far. Does anyone have a tip on how the authorization process would flow for a wearable watch app?
Thanks much!
There is no web browser or direct internet connection on Android Wear devices - all web connections must be done on the phone part of your app and then forwarded to your Wearable app via the various Data Layer API methods - using messages is an easy way to send information in a lightweight, time sensitive manner.
Therefore your phone app should do all of the OAuth dance as part of an initial setup.
I'm working a mobile application for Android and iOS (native in both cases) that will be using Database.com behind the scenes as the database. I need this intergration to be tansparent to the user. The users of the app will not be logging into or authenticating with Database.com at all, it should simply be working behind the scenes a cloud database. I will simply be using an integration user hardcoded into the application.
I've been having an extremely difficult time of finding any of examples of how to build an app with the MobileSDK where I don't have to take advantage of the user-agent OAuth flow that displays a view to the app user. zkSforce has been mentioned as a possible solution for iOS (and it looks like it could be) but I haven't found even any basic tutorials on how to implement this with inconjunction with the mobile sdk to get access to the REST API (by bypassing the login view for the user). I also have yet to find anything at all for Android other than just taking advantage of the standard Java SDK or importing the web service wsdl and working from there through SOAP.
So is there anyone out there who can point me in the direct of some examples of behind the scenes authentication and use of the Mobile SDK REST methods or is my best option here to go to using the SOAP solutions behind the scenes?
Take a look at the OAuth 2.0 Username-Password Flow, which will allow you to use already known username and password with an OAuth-style flow. This is preferred to making a SOAP call in an app that is using the REST API everywhere else.