I want to implement oAuth2 flow in my Slack app, but it's impossible to test properly.
I have added /slack/redirect-url as a redirect URL on my App management page. Then try to install\reinstall the app on the following page:
Unfortunately, it doesn't work, my endpoint isn't called.
However, if I go to the "Distribution" section and try to install the app from there it does call my redirect URL:
So, what's the issue? Why the first approach doesn't call my redirect URL, but the second one does? Am I missing something fundamental?
The "Reinstall App" button will handle the entire exchange of verifying and granting the OAuth token within Slack, so there is no need for the redirect.
The redirect URL is intended for users who are authenticating with your service, and thus you need to store the token.
User clicks the install button
User authorizes through Slack UI
Slack redirects to your desired URL
You grab the code included in the redirect call
You exchange the code for the OAuth token
You store the OAuth token
When you use the "Reinstall App" button in your app management view, steps 3-6 are handled entirely by Slack and the token is displayed to you.
To properly test the redirect URL, you can go through the OAuth flow manually. Given that they're simply GET requests, you can just modify the links and paste directly into your browser.
Step 1: Authorize the app – this will send you to Slack for authorization, and then your redirect
https://slack.com/oauth/authorize?client_id=CLIENT_ID&scope=SCOPES&redirect_uri=REDIRECT_URI
Step 2: Exchange the verification code for OAuth token
https://slack.com/api/oauth.access?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=REDIRECT_URI&code=CODE
Related
We are creating a Xamarin Forms app, only Android for now, which connects to a web API also created by us (ASP.Net Core). I have managed to get OpenId Connect authentication working by:
Using Azure as the identity provider.
Using Android custom tabs to show the Microsoft's login page.
Detect when the custom tab is redirected to our redirect URL.
Get the id token and use it as the authentication bearer token sent to our web API.
Using JwtBearer authentication in the web API.
The problem appears when the id token expires. We want to get a new one without asking the user any question.
To do that, we repeat the authentication process by adding the prompt=none, id_token_hint=THE_TOKEN and login_hint=THE_USER parameters in the authentication request, as defined in the OpenId Connect specification, and supported by Azure.
During that request, we have an issue with the redirect URL:
If the redirect URL has a custom scheme (like myapp://...) Azure responds with an interaction_required error.
If the redirect URL has an HTTPS scheme, then Azure responds successfully (including the necessary parameters to continue the process), but I am not able to detect the redirect URL in the Android custom tab. So my app gets stuck in the custom tab trying to load my invalid redirect URL.
The explanation for #2 is that HTTPS URLs are handled by the browser (Chrome in this case), so it does not trigger any action that I can detect from my app. This seems reasonable.
I also tried to detect custom tab navigation events from Xamarin, trying to detect the event "manually", but failed. Such events are never triggered.
Now, as for #1, I do not have any reasonable explanation. So my question is:
Is there any way to make Azure accept a redirect URL with a custom scheme when trying to refresh an id token by using the standard prompt=none OpenId Connect parameter?
I'm developing an app with Ionic 3 and Angular 4, and also implementing Login With Facebook button (and logic).
I don't understand how to secure this process.
The API returns the user's email + id and then I need to send them to my server to register / log in the user.
But how can I be sure that nobody "fake" the ajax call with those user email & id? And skip the whole Facebook Button process?
I don't get it at all - no matter what the API returns - I need to send it to the server via AJAX, and anyone can fake this process and send specific parameters with AJAX.
A good way is to send the Access Token to the server and make the API call to the Facebook API there. You can/should activate "Require App Secret" in the App settings:
Only allow calls from a server and require app secret or app secret
proof for all API calls.
The answer is - backend!
You should always verify the token in the server side to prevent "hacks" like you said
We have a spa (Angular 2) that we are trying to integrate with okta. I created an app in okta with SWA sign on method. I click on the app and it redirects me to my spa app as expected.
However, I do not see and information being passed on the redirect. How do I validate that the login was successful? Is there some token info that I can validate? Something else?
Thanks!
The SWA sign on method depends on the Okta plugin - do you have it installed? If so, when you hit your login page (and the origin matches the url you've configured in the app), the plugin will try to inject the creds into the login form. It uses a heuristic to figure out which fields to inject into, so ideally your login page will look like a standard login form (i.e. text field for username, password field for password, and a login button).
There are other template apps you can use if you don't want to depend on the plugin being installed (not sure about your setup) - for example, "Template App" will post the credentials to an endpoint (although this is usually not an option since most apps will want to add an XSRF token to their login forms).
I am using the standard MVC 5 identity membership so users can be authenticated to use features on my site. Apart from login and register, ALL actions require someone to be logged in.
I want to use PhoneGap to take my mobile ready html and turn it into a mobile application. I intend to use ajax to do all calls to my actions.
How do I do this with the html pages not residing on the same server? How can I log someone in, and then allow them to make calls?
Authenticating users from mobile devices is fairly simple with the new MVC 5 identity membership. Essentially, every HTTP request that is made to your server from a device will include a bearer token to authorize that request.
When your Web API method receives the request, it will identify the user making it via the bearer token. This allows you to use the standard Authorize attribute in your Web API controllers that I'm sure you're used to using in MVC controllers. Here is a basic example of this process, but essentially it goes like this:
Request containing username and password is made to your server.
Server verifies the username/password and sends back a bearer token
Make another request(s) to your server to access data or other functionality, and include the bearer token in each request
Assuming you're doing this from a mobile device, some options for storing the token are HTML5 local storage, SQLLite, etc. There is no "logging in" doing it this way - there is only authorization of requests to the server. Of course, the user doesn't know that so it's very easy to simulate a typical logged on experience. Here's a brief example expanding on the one one above:
Create a standard login screen with fields for username and password and a login button
User fills it out, and when they click login you make an AJAX call to your server requesting a bearer token with the user's entered credentials (should be over HTTPS)
Server authenticates the credentials and you get a bearer token back. From the user's perspective, he is now "logged in".
One way to handle the bearer token from here is to store it in SQLlite or local storage so that is readily accessible for you to grab and include in any more requests to the server that you make. You just have to take into account that the token has an expiration (set by you, see that link I posted), and design your app accordingly. You might want to tighten down your security by only keeping the bearer token on the mobile device only so long as the user is using the app. When they're finished, you remove it from the storage on the device and the user must go through the authentication process (i.e "log in") again when they open the app.
Additionally, this video Securing .Net Web APIs is definitely worth watching.
I have implemented an OAuth2 authentication mechanism in my GWT app. The OAuth2 server is based on Spring framework 3.x (using its Spring security OAuth2 implementation).
I am using the OAuth2 "Authorization code flow" to get the user authenticated (though implicit flow may have been a better choice in our case). So at first, the user is redirected to the OAuth2 server authentication page, he enters his credentials and if he is successfully authenticated, he is redirected back to a url with an oauth code. He will then make a second call to get an access token from the OAuth2 server.
Now, the issue is, we would like the user to be able to bookmark a page in the application and directly access it. If he has already authenticated then he would have direct access to it (no more auth involved). Otherwise, he would have to go into the OAuth2 authentication flow but in the end, should be redirected back to the bookmarked page he intended to access at the beginning.
How can I store this page url and get redirected to it after the user successfully authenticates ?
any help would be appreciated. Thanks!
EDITED
The initial url redirection is done via javascript's document.location.href
The way to maintain the original URI in an OAuth 2.0 Authorization Grant flow is to pass it in the state parameter so that the redirection endpoint can use it, after it exchange the authorization code for an access token, to redirect the user back to that URI.
FYI, this is exactly what Google suggests in the examples in their OAuth 2.0 documentation, e.g. https://developers.google.com/accounts/docs/OAuth2Login
Original answer:
The problem is using the hash part of the URL for the place, which is not sent to the server and thus cannot be used in the redirection to the OAuth2 server authentication page.
You have 2 (maybe 3) solutions:
stop using the hash for the place and switch to HTML5 History; either through gwt-pushstate at the History level, or a custom PlaceHistoryHandler.Historian if you use the Places API. That limits your audience though: http://caniuse.com/history
stop using an HTTP redirect, and instead use JavaScript so you can put the hash in the OAuth2 redirect_uri. So instead of redirecting, send an error page with the appropriate scripts bits.
some browsers append the hash to the URL after a redirection, so your OAuth2 server might be able to pick it (in JavaScript) and append it to the redirect_uri. That might depend on the HTTP status code used for redirecting (from experience, it works with a 301, but you don't want a 301 here). Needs testing.
You can do this using GWT activities and places.