OpenID Connect Windows Native Samples with Okta

The code samples available in this repository demonstrate the use of Okta OpenID Connect as the authentication mechanism for Windows native apps along with Okta API Access Management for authorizing access to a backend API using Okta's Authorization Servers.

One native app is currently demonstrated:

1. A C# console application using the native browser and the Authorization Code Flow (with PKCE)

Development environment instructions

These code samples were written with Visual Studio 2015 Community Edition Update 3 and we strongly suggest that you use the same development environment (or any other paid-for Edition).

Samples setup instructions

1. In your Okta org, make sure OpenID Connect has been enabled. If not, please send an email to developers at okta dot com to get it enabled.
2. Next, create an OpenID Connect Native app with a Redirect URI value of http://127.0.0.1:[available_port], with the available_port value being a port available on your machine (so that your console app can listen for the browser response on that port. Important note: don't forget to assign at least one user to your new OpenID Connect app!
3. Open the Okta OpenID Connect Windows Native Examples solution in Visual Studio 2015 and in the Okta OpenID Connect Console (Code Auth Flow - Native Browser) project, edit the App.config file to set the following values:
   a. okta:OrganizationUrl: the full url of your Okta org (e.g. https://company.okta.com)
   a. okta:AuthorizationServerUrl: the full url of your Okta org (e.g. https://company.okta.com)
   b. okta:ClientId: the Client ID value of your Okta OIDC Native app.
   c. okta:RedirectUri: a valid redirect uri as set up in your Okta OIDC Native app. This value should be of the form http://127.0.0.1:{any_port}/ and configured as a redirect uri in your Okta OIDC app. Important note: Make sure to include the trailing slash! d. okta:Scopes: the OpendID Connect scopes your application will request from Okta - you can use the default scopes as already configured.
   e. okta:ResponseType: the OpenID Connect response type (can currently be cpde or code id_token)
4. You can test the application with the parameters above and verify that you can sign in with Okta in your browser (or leverage an existing Okta session). You should be able to verify that your console application is able to authenticate you with the same credentials you used in the browser.
5. If you want to test the ability to call an external API (for instance, our ASP.NET Core Web API sample), you must have access to Okta's API Access Management product, which is currently in beta version. If you want access to this product, please submit a request on the Okta beta site and select API Access Management in the Beta Name dropdown list.
6. Once you've been granted access to Okta's API Access Management product, navigate to Security-->API in the Admin dashboard of your Okta organization. You should see a page similar to the screenshot below:
7. Press the Add Authorization Server button and a descriptive name (such as ToDo List API), a resource Uri (such as http://todolist.example.com), as well as an optional description. You should see aenter page similar to the screenshot below:
8. Take note of the Issuer value on this page and copy/paste it to okta:AuthorizationServerUrl parameters in the App.config file of this project.
9. In Okta's Admin dashboard, select the Scopes tab and select the Add Scope button. a. In the window that opens, enter todolist.read in the Name field and Permission to read the Todo List in the Description field
   You should end up with the following Scopes tab: b. In the App.config file, update the okta:Scopes value and append todolist.read to that list
10. In Okta's Admin dashboard, select the Access Policies tab and press Add Policy
    a. Fill out a name and an (optional) description for your policy. b. Select The following clients in the Assign To field and select the OpenID Connect client you previously created. You should now see the following screen: c. Press Create Policy. The following page should appear: d. Press the Add Rule button e. In the Rule Name field, enter a string such as Grant read access to the Todo List f. Uncheck the Client credentials checkbox and check the Authorization code checkbox g. In Grant these scopes select All scopes (in reality, you can layer multiples rules on top of each other, but we're doing this configuration for the sake of simplicity) h. Leave the other values as default and press Create Rule
11. You should now be able to test this command line sample along with a backend API and don't hesitate to send your feedback, comments or suggestions to developers AT okta DOT com!