As per LinkedIn documentation I see that we cannot use the mobile access token to make REST API calls which LinkedIn provides. I have a use case, where, in my mobile app, I use LinkedIn's mobile SDK for logging in to linkedin and I need to fetch certain data like logged in user's connections etc on the backend. This should ideally be done on backend instead of mobile because I do not want too many calls going from app to our servers. Is there any work around to do this?
Actually, there is a way to do requests from backend to linkedin via mobile SDK token.
Such configuration worked for me:
GET https://api.linkedin.com/v1/people/~?format=json
Headers:
Authorization = Bearer ${token}
x-li-src = msdk
Using the Mobile SDK, there's really no way around this at the moment. If you require back-end call capability, your best bet is to use an existing auth library that implements OAuth 2.0 in the mobile environment rather than using the official SDK. That way, the access tokens you get back from the process are usable in either situation.
Related
My company has an internal web app and several other services that use Azure AD for authentication. Because they are SPA and single-tenant, they are able to use implicit grant flow in order to avoid the use of access and refresh tokens.
I am building an internal mobile app that needs to use Azure AD for auth and should also be single-tenant(my org). My understanding is that this is insecure for mobile applications. The only flows I see that apply to mobile include using access tokens to gain access to Microsoft protected API's. I understand that I am able to expose my internally hosted API but that doesn't seem to be allowed in Azure AD with a single-tenant configuration. Therefore I cannot request API access as a scope and the whole system of access and refresh token breaks down.
In addition, all of the client libraries I see are setup for the access token and not sending raw ID tokens or refreshing them. Is something like firebase on top on my app a solution? I have been all over the microsoft docs on this and am struggling.
I understand that I am able to expose my internally hosted API but that doesn't seem to be allowed in Azure AD with a single-tenant configuration.
This is incorrect. You can use Azure AD to secure access to your API even when used by a single-tenant client app.
You can create an app registration for your backend API (where you would define at least one scope), and a separate app registration for you client app (which would request the scope defined for your backend API).
If the client app and backend are really all one logical app, you could also define a since app registration, define at least one scope for it, and the client app would request that scope.
In both cases, the client app ends up with an access token to the backend API, and can use that for API requests.
I strongly recommend not implementing the flows directly. Use an SDK that will handle all the token juggling. The Microsoft Authentication Library (MSAL) for iOS and Android is available for production use now and really makes this fairly trivial: https://developer.microsoft.com/en-us/graph/blogs/microsoft-authentication-libraries-for-android-ios-and-macos-are-now-generally-available/
I have both mobile apps (android/ios) and a website that needs to sign in using linkedin.
On the website, using OAuth is working ok, so no issues there.
The issue I'm having is related to "Sign In" using the mobile SDK, because I need to send an access token to my website server in order to identify that the user is connected and authorized via linkedin.
According to the documentation ( https://developer.linkedin.com/docs/android-sdk-auth )
Mobile vs. server-side access tokens
It is important to note that access tokens that are acquired via the Mobile SDK > are only useable with the Mobile SDK, and cannot be used to make server-side
REST API calls.
Similarly, access tokens that you already have stored from your users that
authenticated using a server-side REST API call will not work with the Mobile
SDK.
So I see no way of using both solutions (web and integrated) in this scenario. If I use a WebView on mobile to connect to the app and sync with my website server, the user experience is not very nice (the webview does not sync cookies, the user has to authenticate in a strange way and does not take advantage of having the LinkedIn app installed on the mobile.
Anyone knows how to solve such a scenario? Thanks!
Yes. It's ok.
Authenticating with the Mobile SDK for iOS
Mobile vs. server-side access tokens
It is important to note that access tokens that are acquired via the
Mobile SDK are only usable with the Mobile SDK, and cannot be used to
make server-side REST API calls. Similarly, access tokens that you
already have stored from your users that authenticated using a
server-side REST API call will not work with the Mobile SDK.
Presently, there is no mechanism available to exchange them. If you require tokens that can be used in both the mobile and server-side
environment, you will need to implement a traditional OAuth 2.0
solution within your iOS environment to acquire tokens that can be
leveraged in both situations.
I'm building a Android/iOS/Web app which authenticates with a provider to receive an access token and then uses the token in the API calls to the node.js backend. I've already got it working for facebook using Passport and the Facebook-Token strategy (https://github.com/drudge/passport-facebook-token)
Now I'd like to repeat the process with this library https://www.npmjs.org/package/passport-google-token
Should be easy, right? But google's developer console for android doesn't provide a client secret. Infact there is very little documentation on what to do if you would like to authenticate on the device and use a token to communicate with the server. It was so simple with facebook, is there something I am missing?
FB's (or Google's) access_token is for their API, not yours. Also, most flows with 3rd party providers like FB and Google are intended for web sites (this is the auth code grant). Devices (and SPA) typically use the implicit flow that doesn't require secrets on the client.
You might want to consider authenticating users with Google or FB (or whatever) in your website (using either strategies which are optimized for web flows), and then issue an API specific token derived from that. I would recommend issuing JWT, which are lightweight and simple to use.
On the API side you could use express-jwt. See here for additional details.
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….