The default value of the redirect URI for a new mobile app registration has a default value which is not a hierarchical URL. Using this value in the Android quick-start sample results in an invalid url exception.
The sample and the documentation require an url formatted like "https://common/oauth2/nativeclient"
The Azure Active Directory v2.0 authentication libraries docs recommend the use of a 3rd party authentication library for Android apps and this is the library used in the Quick-start sample.
Steps:
Navigate to My Applications
Add a new converged app
Add a new platform
Choose Mobile App
See that the redirect URL field is read-only and cannot be changed from "urn:ietf:wg:oauth:2.0:oob" to a hierarchical Url like the one required by the sample docs.
Update the quick-start sample file, oidc_clientconf.xml to set the value to the default value from step 5
urn:ietf:wg:oauth:2.0:oob
Compile and run the app on your Android phone. Choose Connect with Open Id and supply your credentials.
Enjoy the uncaught exception.
You're correct that for native apps you cannot change the redirect URI for v2.0 at this point. Your options are to use urn:ietf:wg:oauth:2.0:oob or https://login.microsoftonline.com/common/oauth2/nativeclient. The latter redirect uri, while not displayed in the portal, is a completely valid, pre-configured redirect uri.
For the particular sample you're looking at, it's using a 3rd party open source library that does not support the urn:ietf:wg:oauth:2.0:oob format. For this case, the alternative Redirect URI exists to allow use of other libraries that have this restriction.
Simply stick that in your sample app (or leave it in there if you're going straight off the sample) and it should not generate this exception anymore.
===========Edit==============
This answer is no longer accurate, you can set custom redirect URIs for v2.0!
Related
I would like to host my ReactJS app as static on Azure Blob. The problem is Azure Blob doesn't support default document. To overcome this, I have set Azure CDN with URL Rewrite rules
for the first source pattern, set to ((?:[^\?]*/)?)($|\?.*)
for the first destination pattern, set to $1index.html$2
for the second source pattern, set to
((?:[^\?]*/)?[^\?/.]+)($|\?.*)
for the second destination pattern, set to $1/index.html$2
This is from the Hao's tutorial
This successfully resolves myapp.azureedge.net but when the client-side routing is used directly e.g. myapp.azureedge.net\react\route the app will return ResourceNotFound.
Meaning when the user inputs myapp.azureedge.net\react\route as his URL and tries to navigate to the page, he will get an error.
I suspect I need to redirect every path, that is not to a static specific file, to index.html. However, I do not know if that's the right solution or how to achieve it
Thank you for Any help!
Azure CDN supports static website hosting now. More information here:
https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website
You can host a single page app without using URL rewrites by setting the default document and the error document to be index.html
I encountered the similar issue before. Assuming that the structure of your static files under Azure Blob container looks like this:
Note: The cdn is the container name.
You could configure the following URL Rewrite rules for setting default page and rewriting all requests to index.html along with the possible query string and your images and scripts under cdn/scripts and cdn/images could correctly accessed.
Additionally, you could use Azure Web App to host your static website and choose the proper pricing tier. Details you could follow Pricing calculator.
There is a new Azure static web app service, currently in preview mode but it is super easy to deploy a modern frontend SPA. You can set up a fallback route (route.json) to redirect everything to index.html, you can see more here: https://learn.microsoft.com/en-us/azure/static-web-apps/
I have followed Adrian Halls book to create a cross platform app with a Mobile Service API backend. I have successfully got unsecured access to the backend working from Android, iOS and Desktop (WPF) clients. I am moving on to adding security to the API using the Authorise attribute. I would like to add social authentication using MicrosoftAccount (formerly passport/Live ID).
Since Adrian wrote his book the Microsoft.Azure.Mobile.Client and the authentication and authorisation landscape seem to have moved on. The samples given in the book no longer build and Microsoft's social authentication and AAD authentication seem to have been rolled into one API.
I have spent days searching for up to date and relevant information but there seems to be lots of stuff on the internet that is either out of date or only shows examples of authenticating using Facebook or Google from Xamarin clients or authenticating against Azure AD.
I am using .NET 4.7 and WPF for the desktop app. I am also using Microsoft.Azure.Mobile.Client V4.0.1. and my questions are:
Should I be using the Microsoft.Identity.Client to authenticate users from my desktop client; and,
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
According to your requirement, you want to use client-flow authentication with MSA. As I known, MSA authentication uses the Live SDK for signing users.
Since Live SDK is deprecated, you could leverage OneDrive SDK for CSharp for logging with MSA, and you could follow the detailed steps for achieving this purpose:
Install the client libraries via NuGet:
Microsoft.OneDriveSDK
Microsoft.OneDriveSdk.Authentication
Log into Microsoft Account Developer Center and create your app, add the native application platform, then Register your app with Microsoft Account.
Then you could follow the code below and add to your WPF application as follows:
For more details about OneDrive SDK for CSharp, you could refer to here and Authentication Adapter for the OneDrive SDK.
UPDATE:
It's my fault. I did not mention that the above code would automatically open a web browser. Per my test, you could configure the parameter returnUrl to https://login.microsoftonline.com/common/oauth2/nativeclient when constructing your MsaAuthenticationProvider instance.
I was in a similar boat - and here is summary from the top of my head - There two security libraries currently in play for authorization- ADAL, and MSAL.
ADAL
This is the first library that came out, and services like B2C must each be handle separately using this library.
MSAL
One security framework to rule them all!
https://github.com/Azure-Samples/active-directory-xamarin-native-v2
This library has a go live license, but technically it's still in Beta.
Head to Mobile.azure.com for the last info in creating a mobile application, and this article on a V2 endpoint.
When you register an application for Authorization - there are two categories a "Converged" application, and a "Live SDK application" ( see https://apps.dev.microsoft.com/#/appList) - why they would choose these names is beyond me to understand. IMPORTANT Translation - Converged application ONLY work with MSAL, the other ONLY works with ADAL. THAT will go a long way for you to get the authentication working, as the Application / Client ID must match the correct SDK, and hence endpoint.
In the end, we chose to stay with ADAL for now as we were having problems with MSAL. MSAL is the future however, as all services will be incorporated, and it should be an easier SDK to use.
Here are some links that I kept, all of which refer to ADAL or MSAL:
http://aka.ms/aadv2
https://azure.microsoft.com/develop/identity
https://learn.microsoft.com/en-ca/azure/active-directory/develop/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/AzureAD
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet
These links are about month old - HTH
I'm writing a mobile app that connects to Azure web services that use ACS access control for authentication. The mobile app is going to be a new version of a website that already exists. The website is already setup in ACS to connect to the web services.
Do I need to create a new entry in the ACS portal for the mobile app or can I just re-use the entry that the website has? If I create a new entry, what would I put in the realm and return URL? Mobile apps don't use URLs so I'm confused.
Thanks.
ACS supports a jsnotify protocol which basically will fire a JavaScript event that the host can listen. However this only works on Windows Phone. The other option you have is to poll the InApp browser (webview) until the URL is equal to whatever you put on the return url. Then inspect the result of the page to get the token, but that's not very easy. The truth is that ACS has not been updated for years and they are behind on mobile scenarios. You will probably spend a week or so trying to get something to work.
You can look at other services like Auth0 (disclaimer: I work at Auth0) which support the same protocol ACS supports (Ws-Fed) and have native support for lots of platforms (ios, wp, windows8, android, xamarin, etc.).
I believe there is an undocumented Google API available to create and manage Google Cloud Console (and App Engine) projects on behalf of third party users.
Does anyone know how to use it?
I think older versions of the Google Eclipse Plugin obtained an OAuth2 token in the (undocumented) scope https://www.googleapis.com/auth/appengine.admin, and this allowed it to generate a Cloud Console project on your behalf. The latest version doesn't seem to do this. App Engine's own appcfg.py also uses this scope, but doesn't seem to do much more than deploy the code - I'm looking to change core settings for the project, such as Name, Redirect URLs, and Web Origins.
Any information would be appreciated.
I maintain a WordPress plugin providing secure Google Apps Login for end users, and currently have to give detailed instructions to admins for creating a new Cloud Console project manually, and entering settings such as Redirect URL. Ideally, I would create a simple on-line service to do all of this for them.
Thank you!
It is possible to programmatically create a new Developer Console project on behalf of a Google Account (yes, you read that right). You do so in a very roundabout way:
Request the https://www.googleapis.com/auth/drive.scripts scope from the user (standard OAuth 2.0 flow).
Use the Drive API's drive.insert method to create a new file with a mimetype of application/vnd.google-apps.script.
Somehow try to get the project ID, maybe by uploading some Apps Script code? This is the part that I was never able to figure out.
A little known fact is that every Google Apps Script project has a hidden Developer Console project associated with it. This project is not shown in the list of projects, but it does exist. It is created automatically when the user starts a new Apps Script project, and the drive.insert method is enough to cause this to happen.
How do you get to the hidden project? Well, the only way I know of is to open the Apps Script project from the Drive website, open the "Resources > Advanced Google Services" dialog, and click the link to the Developer Console. You'll find the project ID in the URL.
Aside from not being shown in your list of projects and not being able to use App Engine, this is a normal Developer Console project. You can add additional OAuth client credentials, service accounts, Compute Engine instances, etc. And of course once you have a project ID, all of the various management APIs will work: creating new virtual machines, making use of a service account's impersonation ability, etc.
We have a requirement to open a web site URL in default browser of the client machine from our WPF application. All this time we were using simple Process.Start(URL) and it was working fine. Until now where one of customer has this "URL" behind basic authentication. The site they want us to browse using URL is hosted on Apache web server. From what I know, if we have https://username:password#domain.com it directly takes us in site without the username/password challenge and it works fine in Chrome and Firefox, however newer version on IE stopped supporting it for security reasons.
Can someone suggest some alternate approach to achieve same considering following objectives ?
List item
Browse to URL with passing in username password.
Open default browser in client's desktop machine.
Don't want to user browser control
At minimum should work in 3 browsers - IE, Firefox and Chrome
We cannot make changes to client desktop's machine, so solution shouldn't require any special settings.
The workaround for developers from the Microsoft Support site : http://support.microsoft.com/kb/834489
Workarounds for application and Web site developers
URLs that are opened by objects that call WinInet or Urlmon functions
For objects that use an HTTP or an HTTPS URL that includes user
information when they call a WinInet or Urlmon function such as
InternetOpenURL, rewrite the object to use one of the following
methods to send user information to the Web site: Use the
InternetSetOption function and include the following option flags:
INTERNET_OPTION_USERNAME INTERNET_OPTION_PASSWORD Note For these
flags, the InternetSetOption option must have a handle returned by the
InternetConnect function. Therefore, if the application uses the
InternetOpenUrl function, modify the application to use the
InternetConnect, HttpOpenRequest and HttpSendRequest WinInet
functions. For more information about how to use these functions,
visit the following Microsoft Web sites:
http://msdn2.microsoft.com/en-us/library/Aa384363
http://msdn2.microsoft.com/en-us/library/Aa384233
http://msdn2.microsoft.com/en-us/library/aa384247.aspx Use the
IAuthenticate Interface. For more information about how to use the
IAuthenticate Interface, visit the following Microsoft Web site:
http://msdn2.microsoft.com/en-us/library/ms775080.aspx
Was this option tried ?