I am working on an app that loads a login page on a WKWebView. My client recently moved to a new MFA provider and this requires the app to allow 3rd party cookies.
I have been trying to allow certain 3rd party cookie but no luck. From hours of research it looks like Apple made this impossible... Is there a workaround to set WKWebView cookie accept policy and/or allow 3rd party cookies from specific domains?
Related
I am writing a native app which uses oAuth. (my app is the client)
At the moment, my app is native to Windows, but I assume that this problem is the same across all desktop operating systems.
To accommodate the oauth flow: My native app opens a browser tab and directs it to the oauth provider.
I am using a browser and not an embedded webview because many Identity providers (ex: google) block non standard browser implementations. ( They want to prevent automated bots).
My app has a small web-server which it uses to listen for the redirect_url called back from the identity provider. Then my app goes on to use said token to access oauth resources from the provider (ex: gmail)
The problem is: When the identity provider (such as google) redirects back to my app, it returns the access_token to my app in the browser's address bar. As such, this token will then appear in the browser history, which will make it very easy for other native apps (or random users using the browser later) to steal my app's token.
What can I do to mitigate this?
How do I prevent the access_token from the oauth callback from showing up in my browser history?
Sounds like you are using Implicit Flow which is the main problem:
Update to Authorization Code Flow (PKCE) so that only a one time use authorization code is returned. Even if an attacker steals it somehow, it will have been used already and the attack will fail.
Another option is to show an Interstitial Page in the browser after login, with a button click to return to your app. As part of that click you can clear the browser tab's history and move to a new location:
history.replaceState({}, document.title, redirectLocation):
See my blog post for some further details on how this looks.
We're building an iOS native app together with two web apps. For identiy/access management we are using Keycloak (supports OpenID Connect and OAuth 2.0).
The iOS apps are installed on MDM managed devices. Only our apps are installed.
I learnt that the current best practice for implementing authentication/authorization is to use OpenId Connect and a browser based flow through an external user agent:
http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007259.html
https://www.rfc-editor.org/rfc/rfc8252.txt
https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
using one of these libraries:
https://github.com/openid/AppAuth-iOS
https://github.com/aerogear/aerogear-ios-oauth2
Is it also recommended for MDM managed iOS devices (with no "evil" third party apps, just our own stuff) to implement a browser based flow? Or is it safe in this case to implement a native login flow (user enters credentials directly into the app)?
I am worried about the user experience... That switch between our app and the browser does not look very smooth...
There is an RFC about OAuth2 for native apps. It's worth reading - it discusses possible implementations and security risks involved. The general recommended way is to use the authorization code flow in a browser (not an internal application component), because this way the application cannot get the user credentials. People use to trust the browser and the authentication provider more than other apps, so the visibility of URL and the verified SSL certificate is important too.
The RFC covers also the iOS implementation details:
Apps can initiate an authorization request in the browser, without the
user leaving the app, through the "SFSafariViewController" class or
its successor "SFAuthenticationSession", which implement the in- app
browser tab pattern. Safari can be used to handle requests on old
versions of iOS without in-app browser tab functionality.
So if you use the SFAuthenticationSession you don't need to open a new Safari window and the user experience should not suffer.
If you use the Resource Owner Password Credentials grant (users enter their credentials into your application directly), you will make it less secure for the same reasons - the credentials get exposed to the application. And using this grant, you cannot use the third party authentication providers in Keycloak (Google, Facebook).
It's up to you (and your organization) how much secure you want the system to be, so you can opt for some compromises, but I would rather stick to the current best practices, since the app may grow later the compromises may turn to problems.
I have a bit of an issue, unfortunately.
I need to integrate a third-party service within my application, and that services requires all user to authenticate via Google OAuth (as it uses Google related services)
The problem is, when signup is completed it redirects to a URL similar to
https://ab.cdef.gh.ik.lm?code=examplecode
I tried adding ab.cdef.gh.ik.lm as a URL Scheme to my app but it didn't work.
The problem stems from Google no longer allowing embedded browsers to authenticate, and I need to use an SFSafariViewController. However, due to limitations in SFSafariViewController, I cannot obtain the current URL and thus monitor when it reaches the ab.cdef.gh.ik.lm page.
Am I out of luck, or is there a way I could handle this authentication?
Thanks!
We're working on a new API that we wish to secure with api tokens. These tokens are tied to a user and an application. These 3rd party applications use OAuth to authenticate themselves (using and app_id and app_secret). This works great.
However, we have our own mobile app which will also consume this API. Obviously I'd like to avoid having the user get asked the familiar "would you like to allow this app to use your account" when performing a login. Obviously we can't embed a secret in the app, (hence pure OAuth would be unsuitable for this). However, I don't want to create an API endpoint to which a username and password can be sent since this would effectively bypass the OAuth scheme entirely.
On the web site, we can just dump the api token into the DOM after a regular form submission, and allow the Angular app to use it from there; but this simply isn't practical in a mobile app.
So my question is; how can we securely identify login requests from our own mobile application? How does (for example) Facebook know that it's the Facebook app supplying the username and password when authenticating, and not some 3rd party application?
As we all know social networks like Twitter, Facebook have their own mobile apps. Other 3rd party apps use their API which can be authenticated over only OAuth protocol after registering for an app.
So how exactly do Facebook, Twitter, Foursquare etc. access their API on their own mobile apps via authenticating by "username" and "password"? I don't think that they just send username and password as parameter on each request.
One more important point is, when you log in those official mobile apps, you don't come across a web interface, asking for permission and has button "Allow this app" which exists in OAuth process. They're authenticated by default!
While investigating I came across XAuth, however after watching its introductory video, it seemed like a shared storage on browser. I'm not looking for that and then I came across use of xAuth in Twitter. It authenticates by sending username/password once over SSL and then server issues an OAuth token/secret pair. (This looks like OAuth v1 instead of v2, which is not cool.)
It looks like what I'm looking for but I'm not quite sure. Are there any alternatives other than maintaining an OAuth server that xAuth requires? Because in my use case, probably 3rd party apps will not exist at all.
In cases like these, the official apps just use whatever authentication they want. I think the point of using OAuth and XAuth for non-official applications are to allow some access to those 3rd parties that (1) can be revoked by the user, and (2) don't require the 3rd party to have the username/password of the user themselves. In fact, before more widespread adoption of OAuth, et al., 3rd party apps requiring your username and password were very common. It was only after Facebook turned off this kind of access, that the OAuth method became more commonly used (in their case).
In the case of the official apps, there's no reason to go through OAuth, because in order to get an OAuth authentication token, you have to enter your username and password anyway. In the case of the official apps, that would make this redundant, and unnecessary.
The official apps could also be speaking to a dedicated set of authentication servers that only accept logins from the mobile app, the mobile app might be providing some special, extra information that identifies it as the official app, or some other mechanism on top of username and password for authentication. I'm not a Facebook developer, so I don't know. But my point is, Facebook/Twitter probably have a separate API password-based logins, and that API is only accessible by the web interface, and other official modes of login.
So, in your case, if you're building a social network (or any web service that will have mobile access) simply use the standard password-based login for your official app, but don't make that login method available to everyone. If you want to allow for 3rd party access through an API, you will really need to setup an OAuth/XAuth server to do this, in terms of keeping your users' passwords only under your control (and not leaked out to 3rd party groups/sites/apps).