I'm using an API that requires oAuth authorisation before it is usable for a React chrome extension.
The app requires me to allocate it an OAuth Domain. The oAuth Domain is described as to be used whenever a redirect occurs from authentication sessions the redirect must go through that domain.
This would be fine if I was using a hosted domain or localhost but I'm not able to use either of those because chrome extensions are held in the browser.
I've been able to navigate to the index.html file of my extension through chrome://extensions/extension ID/index.html, but when I provide that as my OAuth domain it rejects it and says that it must not have a protocol or port.
On the client side (my chrome extension code) I require a channelUrl which is used to for cross domain communication and should be a completely blank fast loading page that matches the OAuth domain.
My problem is that I can't find a way to provide a valid OAuth domain and therefore I can't use the API. Is there a method that would enable Chrome Extensions to work with OAuth redirects?
You need to look at the chrome.identity API.
It allows you to use a web OAuth flow (using launchWebAuthFlow) with a redirect to a URL of the form https://<app-id>.chromiumapp.org/*. The actual redirect to the URL will be intercepted by Chrome and instead pass the data to the extension.
Note that you need to "fix" the app ID of the extension for the URL to be consistent - likely by providing a "key" field in the manifest. Take a look at the docs to that effect - they talk about Google OAuth, which uses a different part of the chrome.identity API, but the concepts are the same.
Related
I'm working on a product with two apps: one a single-page web app, and the other a native mobile app. Both make use of the same backend API. Currently the user authenticates using username/password credentials to establish a session cookie. I'm planning on adding support for authentication using OpenID Connect.
For the web app, I'm looking at following the advice for "JavaScript Applications with a Backend" in "OAuth 2.0 for Browser-Based Apps". In that scenario, the authorization code gets sent to the backend, which obtains the ID token and begins a cookie-based session.
I'm trying to work out how this would work on Mobile. The "go to" implementation of OAuth/OIDC on mobile appears to be AppAuth. From what I can see, AppAuth uses a different approach where you end up doing the auth code exchange on the device to get the ID token.
Should I have the mobile app send the ID token on to the backend to prove the user identity (and then begin the session)? Is there any best practice around doing this? Presumably at least the backend would need to validate the JWT and verify the signature?
Alternatively, can AppAuth be used to do a similar flow as done on the web app as mentioned above?
The mobile case does indeed work differently, and is defined in RFC8252, which defines the AppAuth pattern. Both the web and mobile cases have this in common:
Open a system browser at the Authorization Server URL with a Code Flow request URL
Cookies are not used in mobile views, and mobile apps can store tokens securely, unlike browser based apps. The mobile app will send access tokens to APIs, and also make token refresh requests when needed.
Out of interest there are easy to run versions of each in my online code samples, if you want something to compare against. Both flows are tricky to implement though.
i am trying to login with my facebook but i am getting following error.How can i solve this
URL blocked: This redirect failed because the redirect URI is not white-listed in the app's client OAuth settings. Make sure that the client and web OAuth logins are on and add all your app domains as valid OAuth redirect URIs.
Instead of going accessing the webpage, you use the facebook API instead, they have an open API, where you get an API Key, so Facebook can verify, your application, and not block your request.
https://developers.facebook.com/
depending on your use case, they have several open endpoints, that you can access to get different data, about users, applications etc. For security measures, it is always considered the best practice to use an open API to fetch data, from a specific website.
I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.
OpenID.net claims that:
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
However, I can't find any documentation explaining how to actually authenticate for a mobile app client.
This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.
That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.
Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?
Update
To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?
Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.
So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.
A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.
Please also note that the use of the "Implicit Grant" flow is now highly discouraged.
I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.
This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).
There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.
Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.
https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472
The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:
Google will not vend any client_secret for an oAuth client that is typed "Android"
Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"
Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server:
https://developers.google.com/identity/sign-in/android/backend-auth
This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.
Check out MITREid project on github:
MITREid Connect
This project contains an OpenID Connect reference implementation in
Java on the Spring platform, including a functioning server library,
deployable server package, client (RP) library, and general utility
libraries. The server can be used as an OpenID Connect Identity
Provider as well as a general-purpose OAuth 2.0 Authorization Server.
First of all, I am developing an AppEngine application. As framework, I am using jQuery Mobile. I use GMail API too.
To connect with GMail, I need to work with OAuth 2.0. I have set the credentials into my application (I already have client_secret.json into my project).
My situation is: I am in a JSP page when I call to my Java code (server side) to get my Gmail Service. For this task, I need to get the permissions (Oauth 2.0) from my user. Later, we need to redirect to my application.
My problem is what I do not know what I have to write exactly in "AUTHORIZED JAVASCRIPTS ORIGINS" and "AUTHORIZED REDIRECT URI".
I am testing my application in local mode and the normal URL is: localhost:8888/mobile/index.jsp
Can you help me?
Best regards,
Diego.
Details here
AUTHORIZED JAVASCRIPTS ORIGINS -> Protocols (ie HTTP and HTTPS) and domains (my-app-id.appspot.com) that can use JS and OAuth calls. For local add
http://localhost:8888/
. You will need to add one for the production URL as well.
AUTHORIZED REDIRECT URI -> When doing OAtuh calls from the app it needs a handler setup to get responses from the OAuth server. Personally I use decorators, so my redirect URI is
http://localhost:8888/oauth2callback
. Yours will vary depending on how you handle the OAuth flow.
I understand how the authorization process with Oauth works but is it somehow possible to authorize my access to my endpoints API without the user having to sign in? So what I'm trying to do is to restrict access to my API so that only certain websites, that I allow, have access to it and no others.
In Google APIs console I have created a 'client ID for web applications'.
In your described use case, the preferred solution is to use OAuth. In following the examples in the documentation, you'll be limiting the web sites (via the "JavaScript origins" value for the keys you obtained in the APIs Console).
Sites not listed in the origins will not be able to display the required authentication prompt (the client ID and origin are checked before Google will provide tokens). Developers will not be able to create their own client IDs with their preferred JavaScript origins, because your backend will be checking the client ID of the request is on a whitelist that is part of your code.