Freshdesk OAuth SSO: Freshdesk Login Page Doesn't Ping My Auth Page? - oauth-2.0

I'm trying to connect to Freshdesk using OAuth 2.0, for single sign-on from my app. My app is serving as it's own OAuth identity provider. I've set up my Authorization url on Freshdesk -- let's call it https://www.myWebApp.com/auth:
So now for testing purposes I go to the URL that Freshdesk support provided for a user to initiate the single sign-on process:
https://myWebApp.freshdesk.com/login/normal
...and I see a nice sso-style login screen:
I enter a correct email and password for one of my site users and click "Login".
Now in the Chrome network tab, I would expect to see Freshdesk trying to ping my Authorization URL. But I don't. I see this:
When loaded, my auth page (https://myWebApp.com/auth) pings my server, which issues a console.log() message, and my server logs show no such console log message -- so Freshdesk doesn't seem to be pinging my auth page at all.
What is keeping Freshdesk from pinging my auth page as it should?

There is probably a fair bit here that you have in place already but I am just adding it in for completeness.
Logged into the backend and on the security page for contacts
https://stackoverflow.myfreshworks.com/security/contacts
[stackoverflow == your site :) ]
you will have to create a Custom Policy if you don't have one in place already (this is different to the one for Agents)
And for that configure your SSO with Oauth 2.0
Then , if you have at least one SSO configured your login (at https://stackoverflow.freshdesk.com/support/login ) should look like this:
Where (1) now appears. That will be the link to ping your server via the urls you set up for the SSO:
If you only have one SSO set up for your contacts that link (1) should complete the sign-in process directly and then you should end up logged into Freshdesk as the specific contact.
If you had two SSO options set up; for example:
..when you clicked the link (1) on the https://stackoverflow.freshdesk.com/support/login page, you should then be redirected to a page with those two options:
The url for that page is something like (parameters will be different for you):
https://stackoverflow.myfreshworks.com/login
?redirect_uri=https://stackoverflow.freshdesk.com/freshid/customer_authorize_callback
&client_id=14416083630394368&slug=6117145232763
I am imagining you could use that as a direct link to the portal on your main site.
If you only have one SSO option set up you should be able to navigate directly to the link as above and then see :
which is probably what you are aiming for.
I changed the name of that button (Sign in with contacts SSO) just to be sure I was using the right one and to differentiate from the login for agents. You can change the text under the Advanced Options when configuring the SSO:
Hope this helps you along the way - if you have any other questions on this post them as comments.

Related

Is there a way to remove the URL parameters from an AWS Cognito Hosted UI Custom Domain URL?

I have configured a Custom Domain to be used for my Cognito Hosted UI, so that when users navigate to my web app and are redirected to login, they see a clean URL with branding instead of the scary looking Cognito Domains.
My Custom Domain resembles: auth.example.com
The issue is that when users are redirected to this hosted ui login URL, it contains many Cognito relevant parameters that are not relevant to the user:
https://auth.example.com/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>
I would like for the URL to only show as follows without any parameters: https://auth.example.com
Is this possible or does the Cognito Hosted UI require that these parameters be provided in the URL? Or is there some way to hide the URL parameters from end users?
I've tried simply navigating to https://auth.example.com, but this just renders a blank white page instead of the expected Cognito Hosted UI with sign-in and sign-up forms.
Generally users will only be redirected to the Hosted UI URL or routed there by clicking a button, in which case I'd still like it to be cleaned up without parameters once they're routed, but it would also be nice to be able to share a clean link specifically for signing up, e.g. https://auth.example.com or https://sign-up.example.com.
Thanks in advance for any help!

Via the api, can I force the user to login to reddit?

I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.

How Can I Generate an Instagram Access Token Using their Implicit Flow?

I want to use the Instagram API to show my own content on my own website. I can see in their documentation that content owners can display up to 20 pieces of media on their site while the app is in Sandbox mode.
I've created an app on my account and I am trying to use their Client Side Implicit Authentication to generate an access_token.
I hit this URL and login to my account:
https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=www.mysite.com&response_type=token
When I submit the login form, I am brought to an Instagram 404 page that says:
Sorry, this page isn't available. The link you followed may be broken, or the page may have been removed. Go back to Instagram.
What am I missing? Do I even need an access_token? Before they changed their API last November I was able to use just the client_id in my requests. I suppose that's not possible anymore?
I think you need to include http://.../ for your redirect_uri. So it would be: https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=http://www.example.com/&response_type=token
But of course that means you will also need to add http://www.example.com/ as the Valid redirect URIs in "Manage Clients" on Instagram.

Is this SSO workflow possible?

Let's say I have the following sites: ClientSiteA.com, ClientSiteB.com, ClientSiteC.com, MainServer.com
I am distributing a software to client sites. Anyone will be able to install the software so a site can not be considered trusted. MainServer.com will contain user information.
Users will interact with the software on client sites. A user will be able to click a login link on any client site which will bring up a popup. The popup can reside on MainServer.com. When a user logs in on any client, they will be logged in on ALL client sites as well as the MainServer.com. Remember, MainServer.com contains all user information.
I've done a lot of reading on SAML and OAuth2. Can someone tell me what is possible? If it is possible, which tools/workflows should I use? If this isn't possible, can someone tell me something I can accomplish that is similar to this?
FYI - I am trying to accomplish something like what Disqus does. If you login to Disqus on any site, you are logged into all the sites.
You can accomplish this with SAML, although it will involve browser redirects not popups.
The first time use hits a protected site (ClientA) it redirects to MainServer.com. The user logs in, MainServer gives them a session and redirects them back to the service provider with a SAML authentication statement which then lets them in.
When the user then visits ClientB.com, it also redirects to MainServer.com for authentication. Because the user is already logged at MainServer it can invisibly bounce them straight back to ClientB.com with a new authentication statement. The user barely if at all notices.
The problem with the pop-up window approach is that users have to give their credentials for site A to site B. This is a big security hole if site B isn't owned and controlled by Site A. Users should only give their credentials to the site that is authenticating them to prevent them being compromised. SAML and other federated/distributed auth mechanisms were designed with that in mind. I wouldn't want to give the keys to my email account to random sites on the internet but with this method I can log into stackoverflow with my gmail account.

Multiple Tab apps, using authorization of a single app id

All,
Here is the scenario;
Our website uses APPID-1 for auth and extended permissions (MainSite)
Our Page Tab App uses APPID-1 for auth & extended permission
(TabApp-1), and this adds the auth_token to our DB on MainSite
However we want to add another tab that uses APPID-1 for auth_token acquisition, is this possible?
Proposed scenario;
MainSite - APPID-1 acquire auth_token
TabApp-1 - APPID-1 acquire auth_token
TabApp-2 - APPID-1 acquire auth_token
I should note that non of our TabApps actually need the auth_token, its our MainSite backend app that uses the auth_token to perform actions for the user. However we want to make it easier for our users to use the site, and many come via our Fan Page.
So can we have TabApp-2 pop the Auth Dialog for APPID-1 with is not TabApp-2's APPID?
Specs:
Ruby on Rails 3.1 and using Graph API & Javascript Fb API
I guess you would have to initiate the JS SDK in TabApp-2 with APPID-1. Server-side you would receive a signed_request with TabApp-2 credentials but you can just it that if you work only with the JS API.
I guess you could validate the assumption with a prototype in less than 30 minutes. Have you done that yet? If so, what were the results?
You don't need different apps for this (but i think you're aware of that) the same app can be installed onto multiple pages, and you can show different content on each page by checking the page parameter in the signed_request which is POSTed to your server when the page tab is loaded by a user.
As far as authorisation goes, you may have issues when getting the user to log in directly from a page tab (issues = it may not be allowed to redirect the user back to the tab after login because the full URL to the tab (http://www.facebook.com/pages/somepage/12345?sk=app_{app id here}) isn't 'owned' by your app)
If that happens you can send them to your main site after login with an additional parameter that you use to detect that the user started login on a page tab, and redirect them back to it
Seems you will have to make a few apps, then just use php-sdk to authenticate, since the auth will be server side it will not matter what iframe or page tab it appears in, it will be able to auth to a single app.

Resources