Hello Stack Community.
I'm looking for formal name of technology/technique that's being used in Microsoft Azure CLI and in Epic Games Desktop application, that is responsible for delegation of authentication from target application to browser, where you perform OpenID Connect authentication and brings you back to target application: CLI App or Desktop App, where you can proceed as logged in user by using authentication you gained via browser.
The steps would be:
you launch target app (CLI, desktop app)
login attempt lets you choose oAuth OIDC via Google or so
selecting it opens default browser, where you proceed with login
You gain auth inside app you started from (CLI, dektop app)
In classic OIDC process you gaining your token in same app/browser environment, while here authorization is expected in app A, token is gained in web browser and afterwards there is possibility to re-use it in completely different application.
I'm wondering is this some particular OIDC extension, usage of some particular grant flow or just some particular hacky way of sharing token across entities?
I found one online resource here but my investigation don't confirm starting of any redirection URL localhost server for toke possession.
I'd appreciate any help in my investigation.
Related
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.
I use Google Webtoolkit together with Phonegap to build a mobile app. My app is communicating over a REST APi with my Backend Server.
What I want to do is a user authentication, i.e., my app user should be able to signup and login. If a user closes the app and reopens it, he should be authenticated again if he has not logged out before.
Usually, with Spring Security you do the authentication on the server by calling the required methods. The client (browser) then contains some cookie information for a persistent login.
1. How can achieve this kind of authentication for my app?
2. Should I do the authentication as for a normal web site with the only difference that the authentication methods are called by the REST api methods?
3. Is there another way of doing the authentication for my mobile app?
I think user authentication for the mobile app will be the same as for a normal web-app.
The Spring backend will create a session once a user is authenticated. By default the user is authenticated for the duration of the specific session (until the user closes the browser/app).
Spring Security has a Remember-me functionality that is typically based on a Cookie approach and allows the user to be re-authenticated automatically..
I don't know if phonegap work with Cookies (see here for some pointers). I guess it depends on the plattform (if webview supports cookies).
May be this will help you I wrote an article that show how to adapt Spring Security to secure REST services.
You can check it in here : http://crazygui.wordpress.com/2014/08/29/secure-rest-services-using-spring-security/
I also posted a working example which shows how I did use that with GWT on GitHub.
I have an WinJS metro application that I'm using to connect to a remote webservice that same domain. I read up on the app manifest capability (well the little that is present online) and was hoping that I would be able to use the logged in users credentials to access this webservice without requiring them to login.
I'm trying to authenticate to the webservice via a post using a contentType: "application/x-www-form-urlencoded;charset='utf-8'". This application was previously a website that would prompt the user for login credentials in the authentication step using the aforementioned post. In the WinJS metro application I'm effectively using the same code (minor tweaks) to achieve the same result.
Has anyone had experience with Enterprise Authentication in a WinJS metro application and could better explain what types of resources I would/wouldn't have access to. I'm hoping this isn't specific to accessing things like file shares and intranet sites.
I had this exact issue as well. After ensuring the following Capabilities were enabled in the package.appxmanifest:
Enterprise Authentication
Internet (Client)
Private Networks (Client & Server)
I had to still add the URL of our web service to Internet Explorer's list of Intranet Sites. Only then did the prompt go away.
My app is architected as follows: I have a web service (running on GAE, not very relevant to this question) and the data that this service contains is made available through a website and through mobile and desktop apps.
Currently, the user authenticates to the website via Google ClientLogin and the apps authenticate/get authorized via GAE's built-in oauth provider. (OAuth is being used here mostly for authentication, my app doesn't actually use any external data via OAuth other than the user's unique ID and email address.)
What I'd like to do is expand the number of services that users can use to login. Because of the complicating factor of the apps, it seems I need OAuth. But I can't really properly conceptualize how this flow should go.
Lets take Facebook as an example. When a mobile app goes through the Facebook oauth flow and acquires an access token, this isn't enough - because its my service, not the app, that actually needs to talk to facebook to retrieve contact info and a unique user ID. This leads me to think that the OAuth process needs to happen in the context of my service, and not the mobile app. My service then becomes the consumer and Facebook the oauth providor, and the service holds on to the oauth access token, this happens when a user sets up their account for the first time.
If this is the correct approach, where does that leave authentication for the apps? What happens when the user already has an account and installs a fresh instance of a mobile app? I imagine also going through the oauth process, matching up credentials with the data already stored by my service, and then issuing my own "access token" to the app from the service, to authorize that instance of the app. This seems convoluted and hackish.
I'm sure I can't be the only person who is in effect "borrowing" the account system of a third party for a mobile app with a backend, but I really don't see what the proper way to do this is.
What am I not seeing and/or getting conceptually wrong?
A few colleagues and I once did a project quite similar in nature, back in university. We authenticated our users through either Facebook or Foursquare, using their respective OAuth APIs.
The native Android version of the app opened up a WebView with the OAuth provider's start page, which redirected back to our service after authentication. Then our service did a request for the OAuth token from the OAuth provider (Foursquare has some pretty simple instructions). When we got that token, we set up a session using cookies, which we could access from the app.
To validate sessions, we just checked whether the access token was still valid with the provider. We also used the respective providers' unique user IDs to distinguish users.
So yes, what worked for us is: Make the app authenticate & authorise your service, not the app itself.
I'm currently planning a new web project. Clients are going to connect using a regular web browser and, in case of regular java-enabled cell phones, j2me client. I would really like to make use of the OpenID authentication. In case of regular web browser things are pretty straightforward. However, I am really not sure about installed applications (such as j2me client installed on a mobile device) - regular OpenID authentication is performed by entering username/password on a webpage of particular OpenID provider - which is quite a limitation :)
Has anyone coped with such a situation? Is it possible to create authentication mechanism to the site that uses OpenID from a mobile j2me client?
Currently, I think of solution that users who would like to connect from their mobiles download necessary j2me application from the server web site after they have authenticated themselves (regular browser authentication). The mobile client app could be assembled dynamically on the server with the SSL certificate embedded that is associated with particular logged in OpenID user. After that, j2me client could authenticate to the server without entering any username/password. The data that is going to be stored on the server is not THAT sensitive - considering cases of mobile phone thefts etc.
Can anybody come up with a better solution?
The best solution IMO for what you're doing is to use OAuth combined with OpenID. You're use of OpenID at the RP is fine. But for installed applications that need access to that web site, they should use OAuth to get authorized. The flow would work like this:
User installs app on their device
During install or on first launch, the app has an "Authorize me" button.
The user presses the button and a web browser pops up the web site that the client app needs to access data from.
User logs into that site using their OpenID
Site now asks "do you want to authorize client app X?"
User says yes and closes the browser.
The client app reappears and says "thanks." and now has the OAuth token necessary to access the user's data without the user ever logging in again.