I have an iOS app that authenticates for api access and I have a request to throw the user into safari, not a WKWebView but still keep them authenticated.
Is there anyway to securely share the session between an iOS app and full safari?
I have looked into WKProcesspools but I am not sure that will quite do it.
Not sure about WKProcesspools, but you can share the session using Query parmaters.
Format your weburl to include verification token as a query parameter.
When you verify user via API, you must get the token from response. Pass this token as a query parameter in your url and redirect to Safari.
URL - https://www.example.com/page1
URL with token - https://www.example.com/page1?token=asdfv12324fvfropfc23as
Extra care to prevent copy/paste of token:
When creating token, pass IP Address or MAC Address as parameter of your API and based on these addresses you can check if the request is coming from same address. This will take care of the device authentication.
Related
Hi guy I have a simple diagram to explain what I to achieve
first want to authenticate OAuth with mobile because mobile cant receive a callback from auth server so I need to create new simple node server for handle authentication code and get real token everything just fine until getting real token I already send code
you will see URL that console log print
already attach code in URL
I dint know issue come from guess because different referer who getting and obtain code
because I try to use only server:9000 getting and obtain access token is work
we dont need server for obtain token just only external browser and deeplink
here solove workflow
native trigger external browser
browser send authentication request to auth server
authserver send authorization back to browser
browser trigger some address that associate to app with deeplinking also passs auth code with query param
native capture auth token then send code to auth server for obtain access_token
auth server send access token back to native
native store access token in secure storage like keychain and shared preference
I'm updating my desktop app, an Imgur client, for the upcoming deprecation of code/pin auth methods, by using a local web server to catch the redirect_url from the browser after the user authorizes access to the app. So I launch the URL in the browser, the user accepts, then Imgur redirects to
http://localhost:7710/myapp?state=auth#access_token=....&expires_in=
etc
but the browser cuts the URL at # so all the variables are missing, and my app only receives "state=auth"
from Imgur's API docs:
The response_type Parameter token: This authorization flow will
directly return the access_token and refresh_token via the redirect
URL you specified during registration, in the form of hash query
string parameters. Example:
http://example.com#access_token=ACCESS_TOKEN&token_type=Bearer&expires_in=3600
The code and pin response types have been deprecated and will soon no
longer be supported.
Imgur returns an access token to your application if the user grants
your application the permissions it requested. The access token is
returned to your application in the fragment as part of the
access_token parameter. Since a fragment (the part of the URL after
the #) is not sent to the server, client side javascript must parse
the fragment and extract the value of the access_token parameter.
Clearly they haven't thought this through for desktop applications, or am I missing something?
Imgur stuff looks non standard, since response_type=token is a basic version of the implicit flow, which used to be the solution for single page pps.
These days all UI based flows should use Authorization Code Flow (PKCE) and response_type=code.
Since your app is acting as a (loopback) web server it will not receive the hash fragment parameters, which are only available to JavaScript code running in a browser.
One option that would enable you to get the full URL would be to login via the system browser and to use a Private URI Scheme to call back to the app.
The above link is a visual blog post to explain how this works, in case it is of interest.
I have some programming experience, but only with PHP and Java enterprise systems. But now I have some ideas about a web app in my new job. Since I am new at this, I would like to share how I have done the whole API in a server, browser app and authentication with Google’s OpenID Connect (I read a lot about Oauth and OpenID Connect, most helpful source was this: https://developers.google.com/identity/protocols/OpenIDConnect).
Server: Laravel - hxxps://coolapp-api.mycompany.com
Client: Angular - hxxps://coolapp.mycompany.com
TL;DR version:
1) User goes to hxxps://coolapp.mycompany.com, gets an Angular app login page. Types in their email, clicks “Sign in with Google”;
2) The app sends the email to hxxps://coolapp-api.mycompany.com/api/sign-in. The server redirects the user to hxxps://accounts.google.com/o/oauth2/auth with all the needed parameters;
3) The user logs in to their Google account, gives my app permission if it’s their first time, and Google redirects them to my server at hxxps://coolapp-api.mycompany.com/sign-in/google/callback. The server checks everything, and if it’s all correct, it creates a JWT token and send a redirect to the client app at hxxps://coolapp.mycompany.com/login/callback?token=JWT-TOKEN
4) The client app gets the token, stores it in local storage, and sends it to the server with every API call
More detailed version:
1) User goes to hxxps://coolapp.mycompany.com, gets an Angular app login page. Types in their email, clicks “Sign in with Google”;
2) The app sends the email to hxxps://coolapp-api.mycompany.com/api/sign-in. The server creates a state token and stores it in cache, associated with the email received. Then the server creates Google’s oauth URL and sends it to the client in the response body. I tried to do it with a HTTP redirect, but Google’s server was responding with an CORS error. The Angular app reads Google’s url from the response and goes there.
3) The user logs in to their Google account, gives my app permission if it’s their first time, and Google redirects them to my server at hxxps://coolapp-api.mycompany.com/sign-in/google/callback?code=AUTHCODE&otherstuff. The server sends the code it received (and all the other needed parameters) to hxxps://accounts.google.com/o/oauth2/token. It receives a id_token with that user’s email and basic info. This app is not public, so I don’t want anyone with a Google Account logging in, only the clients whose emails I added to the server database. So now the server checks if the user’s email in the token is in the database. If it’s not, it sends the user a HTTP 401 - Unauthorized. Then the server checks the state token in it’s cache associated with the email received. If it’s equal to the one received with Google’s redirect, then the server creates another JWT token, but now signed by my server. Finally, it sends a HTTP redirect to hxxps://coolapp.mycompany.com/login/callback?token=JWT-TOKEN with the new token.
4) The client app gets the token, stores it in local storage, and sends it to the server with every API call
Some comments:
Everything is HTTPS;
I added the strictest CSP policies I could to my Laravel server and Angular client;
Currently the app only supports Google’s sign in, while it is in development. Later on I’ll add more.
I made that my server only checks if the user’s email is in the database after they logged in with google because I like that idea that a non-authorized user should have no information about anything. If I made that check before it, during the first round trip, anyone could type an email and discover if that email has an account in my system;
On the last step, when my server sends the JWT token to my client app, I tried sending the token within a cookie, but since my API and my client app have different domains, my client app couldn't read the token. Sending it in the url was the only solution I could find. I tried logging in a popular app that uses Oauth and they did it this way too.
So my question is:
Am I doing something wrong, unsecure, weird?
Thank you all very much
1) Entering an email address every time a user wants to log in is tedious. And it's not needed if the user is already logged in at Google. The user should just click the "Log in with Google" button and get logged in without entering anything. The state parameter can be a random string - not related to the user's email in any way.
2) If you want your backend to process the redirect from Google (using the auth code flow - the backend has the client role in OAuth2 terms), the backend should also initiate a redirect to Google - not by sending data containing the redirect URL. To achieve it, after clicking the "Log in with Google" button, perform a whole page navigation (instead of an XHR request) to /api/sign-in and if the backend returns HTTP 302, the browser will correctly redirect to Google.
3) You should perform request validation (the state parameter) before getting tokens and checking whether the user exist.
On error (access denied), you can consider redirecting the user to an error page with error details instead of returning HTTP 401, since the HTTP code will cause a generic error screen to be displayed to the user. If you want to keep using HTTP codes, I think HTTP 403 Forbidden would be more appropriate.
4) Consider using sessionStorage instead of the localStorage. The sessionStorage gets cleared after closing a browser/tab and it's not shared among tabs. It makes it safer and it allows users to use different identity in different browser tabs.
The tokens your backend issues, is their validity time limited? Is the user required to get a new token after some (short) time period? If not, valid token vales may stay in the localStorage and browser's page history, which can be a security problem.
You can consider using your own OAuth2 auth server (such as RedHat Keycloak) which would accept Google (and later some other providers) for authentication and it would also issue access tokens accepted by your backend.
In the web api for /authorize a refresh and access token are returned. How can I access/ receive a refresh token similar to what is returned in /authorize?
Something like SPTAuth.defaultInstance().refreshToken?
You need to create a URL scheme for your app. Something like:
appName://SpotifyAuthentication
Then when you register your dev account with Spotify, you need to enter that as the redirect URI. When you make the request on the device (GET https://accounts.spotify.com/authorize?client_id=.....&response_type=code& redirect_uri=appName%3A%2F%2FSpotifyAuthentication&.....), it will call this URI automatically and will call: application:openURL:options: in AppDelegate.
The URL query string will contain your auth token. IE: appName://SpotifyAuthentication?authToken=someToken.
In my application, I have a screen where user clicks different types of files to view and download them. However this screen is only accessible after user is logged in through web site.
I launch the Safari browser with my URL by using this method:
UIApplication.sharedApplication().openURL(NSURL(string: url)!)
However, the user is being redirected to login screen because he is not authorized to use the website yet.
My question is, how to pass cookies or headers to Safari and launch the URL with those?
You can't do that directly. openURL does just that, no more.
You need to pass required credentials in the URL. The target server may read them from the URL and then set desired cookies in the response.
If you implement that, make sure it can't be abused to set arbitrary cookies or perform session fixation attack. One way to implement that securely is to use one-time identifiers:
In the iOS app contact the server using a valid auth cookie and ask for a one-time long random key, which the server needs to store for a while.
Redirect user to URL with ?key=<that one-time key>
Make the server verify that the key matches and set cookies for the user, and delete the key.
Be careful with passing any secure data in the URL query as it's considered to be a security risk.
Some reasons are:
URLs are stored in web server logs
URLs are stored in the browser history
URLs are passed in Referrer headers
Reference: https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
I know it's not what you are looking for, but more secure solution would be to use session level cookies together with WKWebView. Check this SO answer for more information https://stackoverflow.com/a/26577303/14009088