We have an issue with OAuth2.0 connection to our backend. Failed to verify connection 400. We see that verify connection goes through “refresh”, and refreshToken is empty, that’s why 400 occurred.
It looks like the flow is authorize → refresh instead of authorize → token → refresh. And that’s why refreshToken is empty.
Anybody an idea how to resolve this?
Related
I have a power automate flow which starts when a http request is received.
To continue on, I need to have the microsoft user of the person who is calling the link. Is it possible to make a redirect to login.microsoftonline.com or something else? How can I read the users email?
UPDATE: I tried to handle this with a custom connection to the microsoft graph api. I set "enable onbehalf of login" to "true".
But now I get the following error:
Connect cannot be used to activate this flow, either because this is not a valid connection or because it is not a connection you have access permission for. Either replace the connection with a valid connection you can access or have the connection owner activate the flow, so the connection is shared with you in the context of this flow.
My SignalR app use JWT authentication cookie for authentication. For testing I set the jwt exp payload to 3 min.
I tested in Chrome browser, transport using serverSentEvent.
I have a button on page which will trigger Hub's server method.
After 3 min, when I click on the button. The Hub will response 403 forbidden error. I guess it is because my jwt token expired.
However if then I reload the page, the hub still connected and started. The page still use the same cookie sent to server. When I click on the button to trigger server's method. This time it will not return 403 error. The server method still get called. But inside the server method, the Context.User.Identity.IsAuthenticated = false.
I can't understand why on the first load will trigger 403 error, but not on the reloaded page.
I want to catch the unauthorize access to signalr, if the jwk token is expired or contain invalid data, I will redirect to login page.
What http code should i respond with if I cannot find a user in the database and therefore, cannot authenticate him.
I personally do not like like idea of returning 404.
I would recommend either 401 or 403 .404 is not found which could be also because resource is not available even user is authenticated. Ref Standard Error Code
401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
Which status code would you use in this scenario, assuming you're using a token based authentication:
The client has a token and makes a request to the server.
The token expired and the server sends a 401 Unauthorized.
The client sends the refresh token.
The token is invalid and the server responds with XXX?
The use case would be an application, that automatically catches 401's and makes a request with the refresh token. If the server would respond with a 401 if this token is not valid, the client would try to request a new access token with the refresh token forever. But it should tell the client, that it should re-authenticate with its credentials (e.g. email and password).
I was just wondering which status code would be the best fit in this scenario, as the spec says in case of a 403 Forbidden "authorization will not help".
I would not make access and refresh tokens interchangeable: Use Access-Tokens to access protected resources and use Refresh-Token to fetch new Access-Token from a special end-point. OpenID Connect works this way.
You would have one HTTP request more but HTTP codes would not be a problem and, in my opinion, you would get a cleaner code.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.