OAuth Implicit flow is failing, Navigation is blocked: assistant-handoff - actions-on-google

We are trying out oauth implicit flow for Smart home integration with google actions.
After successfully authenticating userid and password, redirection against redirect_uri (Sample given below) is failing with the below error (Extracted from android logcat).
"Navigation is blocked: assistant-handoff://complete/?result_code=FAILURE&result_message=Account+linking+failed", source: https://assistant.google.com/services/auth/handoffs/auth/complete (0)
Redirection URL triggered from server side:
https://oauth-redirect.googleusercontent.com/r/connectedghome#access_token=xxyuy12&token_type=bearer&state=CtgCQUx3MExZRXhBdlVRVHpxajBHSUFZTktVXy11V0d3a0Q4dndOZWVybndCaVpzVDR5THVJajVhWUNpMkRvSnd2eG1PTVRsRW5idjRPaUFoeHREeEY5dUFrU01kOW00SkVkTnZEX0pGNTA5R0RwTlJYcDN3Q2R5aE1XLXJXUnlzVW5iaUk3OU9YUDIya0dZWnNqeU02Ny04a3NYS0dfZXVsV1YtX19iZmpndGtheXAwdHJKYzFUOUgxT3FtR0JrNjRXSFBnc2JFRzA2cnVmSlZmNmlGbFRxek9zcGhadVJJWmhoX2tBekhsNzVvWWlSYS1FTTFPR0dOcml1ZTNORVozck9kUldwYko5TnU2aWctazAyVnhTVjNiNFVScGhZX3JOQ1BtcF9aazM3aFJvZzluSmFqWHp3U0tCYUtnMnlXb3UxMXJKWDc5aFotYThsVXlVYUR2NWV1UFoSHGFzc2lzdGFudC1oYW5kb2ZmOi8vY29tcGxldGUiPWh0dHBzOi8vb2F1dGgtcmVkaXJlY3QuZ29vZ2xldXNlcmNvbnRlbnQuY29tL3IvY29ubmVjdGVkZ2hvbWUqHGNvbm5lY3RlZHNtYXJ0bGlmZUBnbWFpbC5jb20yEmNvbm5lY3RlZGdob21lX2Rldg",
source: https://connected-safehome.in/smarthome/ui-auth/js/main.js?id=2 (109)
Kindly help us out or give us some hint on how to resolve this.
The complete flow works in OAuth playground app.
This has become a blocker.
Thanks & Warm regards,
Pradeep

You cannot use implicit flow for a smart home integration. You have to use an authorization code as described in the documentation:
Make sure that you have a public OAuth 2.0 server for authenticating users and apps. It should conform to the OAuth 2.0 Authorization Code flow.

Related

How to authenticate and authorize a user in username/password and google sign in?

The architecture of the system is like this
User can log into the website using either username-password approach (after registration) or a google-sign-in.
I want to know how can I implement authentication and authorization for this scenario.
Here is what I am thinking of implementing :
Have an REST API server built over NodeJS and Express.
The login and registration processes are handled by this server as well.
The authentication is done by using JWT Tokens stored in the client side. And these tokens are then used again for authorization of endpoints as well.
How much secure is this approach? And how can google sign in be added to this architecture.
And also if a seperate server for making auth requests is needed as mentioned in OAuth 2.0?
It would be better if the system remains Stateless to follow the principles of RESTFul APIs.
This post that I have written might give you some insight.
https://dev.to/ralphwjz/login-management-for-spa-and-everyone-else-12o6
The post covers Github login but if you replace GitHub with google, the rest of the flow is exactly the same.
I can answer more questions once in context

How to get a JWT from Auth0 hosted login

According to the "tutorial" (the docs themseleves say nothing) Auth0 should set a JWT for me on login, but it's not clear what it means by this. How do I get that JWT?
We already have a login flow in place that uses a hosted page that is accessed through a CNAME CNAME.example.com. Following this process:
I go to example.com/login
I am redirected to the CNAME CNAME.example.com/authorize?...
Then again to CNAME.example.com/login
Username and Password are POSTed to CNAME.example.com/usernamepassword/login
This returns a form containing the JWT and automatically POSTs to CNAME.example.com/login/callback
This then redirects back to our main site example.com/langing-page but the JWT is not received here.
Because it's a CNAME, Auth0 would be able to set an HTTP Only, Secure cookie for our domain, that would be enough.
I've only just jumped on this project and understand that if it was built from scratch we could use the API directly to get the JWT but I can't work out how to do it for the existing flow.
I'm sure we're missing something simple, but the documentation is not forthcoming. Do I need to do a login via the API instead?
EDITED: To clarify the login flow exists and works using a hosted page on auth0, I need to get the JWT after the user has logged in.
MORE INFO: We're using the Auth0 WordPress Plugin which correctly logs us in as the right user (as well as helps us create new users) but does not seem to expose the JWT. That page does mention getting JWTs but refers to the deprecated wp-jwt-auth plugin
The links provided is for general information about JWT's; for accomplishing an authentication through Auth0 there are better suited documentation. In particular, you should start with the quickstarts (https://auth0.com/docs/quickstarts) to check if there's any that is directly associated with the application and stack you're building.
In addition to that, you can also check the docs associated more with protocol flows (assuming you want OIDC/OAuth 2.0): https://auth0.com/docs/api-auth/which-oauth-flow-to-use
The above should guide you about which flow to use and then for each you can follow the links to have a better understanding of how the flow can be implemented.
As an additional note the /login endpoint should be treated as an implementation detail; for OIDC/OAuth 2.0 you need to start the request at /authorize.

Is there anyway to authenticate a user with Github without redirecting them within the current page?

I am looking to allow a user to sign in with github for a website I am creating that will be API driven. However, I am running into a problem that there seems to be no way of authenticating a user and getting their email and name without redirecting them on the current page to github. I have tried to create a popup, but there is no way for me to get the necessary data from the popup, namely an api token to be used for the next calls.
The answer to the question as framed is "use a different grant flow" but your questions tell me you don't understand OAuth grant flows so you may be better served by a lecture on OAuth.
Popups and iframes are specifically designed to prevent code running outside them from fishing out data, because if you could do it so could invisible iframes in dodgy ads. Give up on that approach because in the unlikely event that you find a way, browser makers will immediately take steps to prevent your solution from working.
The behaviour you describe sounds to me like implicit grant flow.
Here's a walkthrough of the various ways OAuth2 can work.
Why so many ways?
Implicit grant is a flow that uses redirection to deliberately take control away from your code - which might be compromised or impersonated - and give it to a trusted third party, the OAuth provider: GitHub in this case. You pre-register the point to which control is returned after authentication, the point of which is the token is always given to your code.
Amnesia, popups, and what was I doing before we were so rudely interrupted?
There are flows that use popups. Usually this is the authorisation code grant flow. Popups are not suitable for mobile devices and this led to the creation of the implicit grant flow.
The usual reason for not liking redirection is the amnesia it causes. The solution is to store app state persistently prior to passing control to the OAuth provider, and to write a return-from-oauth handler that unpacks the JWT from the redirect parameter and then restores the app state you saved.
Note to self
If the user is anonymous prior to authentication serialise your state to a string and put it in a cookie or in localStorage.
If the user is not anonymous and is authenticating to elevate privilege you'll have to send any privileged data to the server and just persist a retrieval token on the browser. You must ensure that retrieval of this state requires both a valid OAuth token and a valid state token, and that it discards the state after honouring a request so that a replay attack will be conspicuous (you'll have to handle the fallout).
Having acquired a valid token you can use it to request profile information from GitHub. A very small amount may already be present in the JWT; you'll probably have the email address that served as a login, but this isn't necessarily the right one for correspondence.
GitHub OAuth documentation
It appears GitHub only supports code grant auth. That means you have to do the popup/iframe thing. Here's their doco:
https://developer.github.com/v3/oauth/
Code grant - why?
This flow doesn't give you an encoded token, it gives you a code you can redeem for an encoded token. The idea is that when the token expires you can use the code to get a refresh token without sending credentials over the wire.
Not only you have a redirection, but starting Dec. 2020, you also have:
OAuth 2.0 Device Authorization Flow now GA
GitHub Apps and OAuth Apps now feature GA support for the OAuth 2.0 Device Authorization Grant, in addition to the existing Web Application Flow.
This allows any CLI client or developer tool to authenticate using a secondary system with a browser.
GitHub CLI uses this authentication method on the login command.
Read the full documentation on Authorizing OAuth Apps and Authorizing Users for GitHub Apps for more information.
Confirmed March 2022:
Enable OAuth Device Authentication Flow for Apps
From today the OAuth Device Authorization flow feature must be manually enabled for all OAuth and GitHub Apps.
This change reduces the likelihood of Apps being used in phishing attacks against GitHub users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication.
If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you can enable it for your App via its settings page:
The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not enabled this feature.
Documentation: "Device flow"

"Developer Inactive" on Beats Music server-side auth token request

I'm working on a project and a new Beats Music API library for Clojure, but in my testing I'm finding it difficult to get write access authentication, but read-only user authentication works fine.
In testing my library I set up a HTML page to do the OAuth and get the OAuth code and then feed that code in to my library to fetch the actual authentication token. The first part works flawlessly, the second part has the dreaded "Developer Inactive" error:
URL: /oauth/token
PARAMS: client_secret, client_id, redirect_uri, code, grant_type=authorization_code
METHOD: post (application/x-www-form-urlencoded)
I've double checked my redirect_uri is the same as defined in my app settings and is the url of the HTML page I generated the code with. I even checked with the support folks to double check that my application wasn't throttled or something, but that took too long and I made a second application and had the exact same results. I've looked at other support questions like this and nothing has helped, so unless I'm missing something in my auth request, my only other thought was that my user account is still on it's 14-day trail and maybe that is affecting my auth token in some way?
Any ideas or suggestions would be greatly appreciated.
From https://developer.beatsmusic.com/docs/read/getting_started/Client_Side_Applications
"The scope of an access token using the implicit flow is limited to read only since client side applications cannot keep a secret. You'll need to request the authorization grant flow via the Web Server Authentication for write permissions, such as updating a playlist."
I hope this helps.
As #jsd pointed out in a comment on my question, there was a typo in the url endpoint. The correct endpoint is (which I had in the other function and that's why it was working correctly):
/oauth2/token

Browser test tool for OAuth2 "Client Credentials Flow"

Till now, the REST API application we've been developing has used a simple api key passed in as a URL parameter, but we've just switched to using the OAuth2 Client Credentials Flow.
This is the simple workflow in which a client POSTs a key and secret via basic authentication and receives an expiring access token. Unfortunately, simple as it is, it's made it considerably more difficult to do quick tests of the API in a browser, either during development or for our support team to do installation sanity checks.
I've tried OAuth 2.0 Playground and REST Console for Chrome, but both of these only seem to support the more complex Authorization Code Grant workflow. Is there a browser-based tool that supports the Client Credentials flow?
Here's my configuration for testing the client credentials flow using the Chrome extension, Postman.
You can actually configure the OAuth 2.0 Playground to use the Client Credentials flow. Just click on the "Wheely" icon on the top right to open the configuration menu and select the "Client Side" Flow.
Another trick you can "Restore" the Playground by generating a URL (click on the "URL" ico on the top right). For instance use this link to have the playground configured for the Client Credential flow automatically: https://developers.google.com/oauthplayground/#step1&response_type=token
Suggest you try Google OAuth 2.0 Playground (https://developers.google.com/oauthplayground/). While it is optimized for Google-specific OAuth2 flows, you can custom configure the OAuth Endpoints and other parameters to use your flow. You'll just need to make sure to use https://developers.google.com/oauthplayground (no trailing slash) for your redirect URI, or you'll get a redirect mismatch (if your system checks that.) Once configured it lets you save a parameterized URL so you don't have to type in all of the configurations the next time you go there.
Currently looking for other tools as well. Happy to post any others I find.