OAuth

Labels
AJAX(112) Apple(1) Application Builder(242) Application Factory(207) ASP.NET(95) ASP.NET 3.5(45) ASP.NET Code Generator(72) ASP.NET Membership(28) Azure(18) Barcodes(3) BLOB(18) Business Rules(1) Business Rules/Logic(140) BYOD(13) Caching(2) Calendar(5) Charts(29) Cloud(14) Cloud On Time(2) Cloud On Time for Windows 7(2) Code Generator(54) Collaboration(11) command line(1) Conflict Detection(1) Content Management System(11) COT Tools for Excel(26) CRUD(1) Custom Actions(1) Data Aquarium Framework(122) Data Sheet(9) Data Sources(22) Database Lookups(50) Deployment(22) Designer(177) DotNetNuke(12) EASE(20) Email(6) Features(99) Firebird(1) Form Builder(14) Globalization and Localization(6) Hypermedia(2) Installation(4) JavaScript(20) Kiosk(1) Low Code(3) Mac(1) Many-To-Many(4) Maps(6) Master/Detail(36) Microservices(4) Mobile(63) Mode Builder(3) Model Builder(3) MySQL(10) Native Apps(5) News(15) OAuth(5) OAuth Scopes(1) OAuth2(6) Offline(14) Oracle(10) PKCE(1) PostgreSQL(2) QR codes(2) Rapid Application Development(5) Reading Pane(2) Release Notes(163) Reports(48) REST(26) RESTful(21) RESTful Workshop(13) RFID tags(1) SaaS(7) Security(75) SharePoint(12) SPA(5) SQL Anywhere(3) SQL Server(26) Stored Procedure(4) Teamwork(15) Tips and Tricks(81) Tools for Excel(2) Touch UI(93) Transactions(5) Tutorials(183) Universal Windows Platform(3) User Interface(331) Video Tutorial(37) Web 2.0(100) Web App Generator(101) Web Application Generator(607) Web Form Builder(39) Web.Config(9) Workflow(28)
Archive
Blog
OAuth
Sunday, March 13, 2022PrintSubscribe
OAuth 2.0 Configuration in Postman

Postman in the popular API development tool. RESTful Workshop recommends this tool when exploring the RESTful API Engine. The engine is an integral part of applications created with Code On Time. It supports authentication with API Key and OAuth 2.0 Authorization Code flows. It relies on access tokens to identify the users when client apps are making requests to the RESTful API.

Postman makes it easy to acquire an access token with OAuth 2.0 Authorization Code flow with PKCE.

Workshop segments SPA4 and SPA5 explain how to build a single page application capable of authenticating users with OAuth 2.0 Authorization Code flow with PKCE. This particular flow is suitable for native mobile applications and single page applications. Both are not able to “keep a secret”, since the source code, binaries, and external settings can be explored by 3rd parties.

Proof Key of Code Exchange (PKCE) provides the means of producing a dynamic secret instead of relying on a static secret. Dynamic secret ensures a secure exchange of an authorization code for an access token between the client application and the server.

Request Authorization

Authentication with most OAuth 2.0 flows starts with a user pressing the Login button in the client app.

  1. The browser window is redirected to an Authorization URL pointing to the backend web application. Native apps open a special Web View for the same purpose.
  2. Users are asked to sign into a familiar application they know and trust.
  3. Users confirm their identity with the optional 2-Factor Authentication or set up a new account.
  4. Authenticated users are asked to allow access to their account.
  5. If account access is granted to the client app, then the backend application will redirect to the location specified in the Authorization Url.
  6. Client application collects the authorization code specified in the redirect URL by the backend.
  7. Client exchanges the authorization code for an access token.
  8. The token is retained by the client application and specified in the Authorization header of requests to identify the user to the backend.
Postman will act as a native client application to acquire an access token from the backend.

Developers will need to know the details of the client application registration and OAuth 2.0 API endpoints.

Start Postman and create a new HTTP request. Enter the localhost address of the backend application followed by the /v2 path in the request URL. Select the Authorization tab and choose OAuth 2.0 in the Type field. Additional settings will appear.

The Current Token section allows selection of the access token for the request authorization. The tokens are retained by Postman after each successful authorization request approved by the user.

Authorization tab of the new HTTP Request in Postman configured for OAuth 2.0. Developers can select the current token for the request and setup parameters to capture the new tokens.
Authorization tab of the new HTTP Request in Postman configured for OAuth 2.0. Developers can select the current token for the request and setup parameters to capture the new tokens.

The Configure New Token section allows capturing and naming the new tokens. Captured tokens will appear in the Available Tokens drop down of the Current Token section.

New Token Configuration

Here is the full view of the parameters required to configure the capturing of new tokens. This set of parameters allows collecting access tokens from any OAuth 2.0 Authorization server.

Applications created with Code On Time have the built-in OAuth 2.0 Authorization API and will work with any OAuth 2.0 client including Postman.

Configure New Token section allows setup of a separate request to capture a new access token from the backend application.
Configure New Token section allows setup of a separate request to capture a new access token from the backend application.

Follow these steps to configure the request on behalf of SPA4 to acquire a new token from the RESTful Application Backend created with Code On Time:

  1. Token Name: enter admin as the value. Typically this is the user account name.
  2. Grant Type: choose Authorization Code (With PKCE) in the dropdown.
  3. Callback URL: enter http://localhost:9090/spa4.html#auth) as the value. This is the redirect_uri from the client application registration.
  4. Auth URL: enter http://localhost:42439/oauth2/v2/auth as the value. This is the href value from the authorize hypermedia control available in OAuth 2.0 API of the backend.
  5. Access Token URL: enter http://localhost:42439/oauth2/v2/token as the value. This is the href value from the token hypermedia control of the OAuth 2.0 API.
  6. Client ID: enter TKuyzeDmIQKWFVncJcKpCXCWEmcsJP3kB9QpudegTrC as the value. This is the client_id from the client application registration.
  7. Client Secret: leave the field value blank.
  8. Code Challenge Method: set value to SHA-256.
  9. Code Verifier: leave the field value black. Postman will automatically generate the value.
  10. Scope: enter offline_access openid profile email as the field value. This space-separated list of scopes will yield the access_token, id_token, and refresh_token if the authorization request is approved by the user.
  11. State: enter any random sequence of characters. For example, enter 12345.The state is returned with the authorization code upon approval of account access by the user. Client application will compare the specified value with the one specified in the url to detect the forged request.
  12. Client Authentication: leave the default value.

Note that the port number in the localhost addresses above will be different for each implementation of the backend. Use the client application registration property values of your own backend application.

Parameters in the Configure New Token are set for OAuth 2.0 Authorization Code flow with PKCE.
Parameters in the Configure New Token are set for OAuth 2.0 Authorization Code flow with PKCE.

Click the Get New Access Token button. Postman will open a hosted browser window.

Postman opens a hosted web view to capture the authorization code in the OAuth 2.0 Authorization Code flow.
Postman opens a hosted web view to capture the authorization code in the OAuth 2.0 Authorization Code flow.

Sign into the backend application with the username admin and password admin123% to be greeted with the Account Access confirmation.

Allow account access to the Standalone SPA4 with RESTful Hypermedia and OAuth 2.0 client application. Postman is impersonating SPA4 here and therefore its name is displayed at the top of the account access prompt.

User approves the Account Access for the client application in the hosted web view controlled by Postman.
User approves the Account Access for the client application in the hosted web view controlled by Postman.

Backend application will redirect to the URL specified in the Callback URL parameter in the Configure New Token settings. URL will be altered to include the authorization code value. It will also have the copy of the state parameter from the Authorization Url.

Postman will display the message Authentication Complete if it was able to extract the authorization code from the redirect URL constructed by the backend application after approval by the user.
Postman will display the message Authentication Complete if it was able to extract the authorization code from the redirect URL constructed by the backend application after approval by the user.

Confirmation of the successful authentication will close automatically after a short delay since the Postman will have only two minutes to exchange the authorization code for an access token. The response from the exchange will be presented in the Manage Access Tokens window.

Postman exchanges the authorization code for an access token with the backend application. The response is presented in the Manage Access Tokens window.
Postman exchanges the authorization code for an access token with the backend application. The response is presented in the Manage Access Tokens window.

Press the Use Token button to set the user identity of the HTTP request.

Developers can see the current Access Token and Header Prefix on the Authorization tab.

Current access token is displayed in the Access Token field. Header Prefix is automatically configured.
Current access token is displayed in the Access Token field. Header Prefix is automatically configured.

Developing With Tokens

Developers impersonate users in three easy steps when configuring an HTTP request:

  1. Select Authorization tab of the HTTP request
  2. Set Type to OAuth 2.0.
  3. Choose Access Token from the list of available tokens.

Postman makes it easy to select an available access token to authorize a request.
Postman makes it easy to select an available access token to authorize a request.

Tokens will expire periodically. Requests submitted to the backend application will return an error with HTTP code 401 when this happens. Developers can revisit the Authorization tab of the request and acquire a new token. Postman preserves the Configure New Token settings. A single click on the Get New Access Token button will open the backend application in the hosted browser. Developer signs in on behalf of a user and approves account access. The new access token is available!

Learn how to build a single page application with OAuth 2.0 Authorization and OpenID.
Labels: OAuth, PKCE, RESTful
Thursday, September 30, 2021PrintSubscribe
2-Factor Authentication

 Multi-factor authentication

A combination of a username and password provides access to the personalized features of applications. Unfortunately both elements of the online identity are the primary source of the security breaches. Username and password are obtained by perpetrators through social engineering attacks, spy programs, and other nefarious means. The complexity of our lives forces us to share the passwords with loved ones and friends. The robust mechanisms of online identity protection are urgently needed in every application.

Many organizations adopt security systems that require the end users to enter a numeric time-based verification code generated by an authenticator app installed on the user’s mobile device. The unique secret key is associated with the user account in the application database. Authenticator app uses the same secret to generate a new verification code periodically and does not require a network interaction with the application. If the correct verification code is not provided at the time of sign in, then the access to the application is not granted even if the user is entering the correct username and password combination.

The username, the password, the text message or email with the verification code, the phone with the authenticator app with optional fingerprint scan or face recognition are the components of the multi-factor authentication.

2-Factor Authentication Setup

Applications created with Code On Time can force the end users to provide an additional piece of information to confirm their identity after the username and password were confirmed. By default, the 2-Factor Authentication is the opt-in feature. It can be enabled in the user context menu.

 
The option “2-Factor Authentication” is available to the authenticated user. The 2FA setup is not available to the end user if the user identity is confirmed by an OAuth provider. Application will rely on the authentication verification methods of the provider instead. The initial activation of 2FA will require the user to confirm their password.


Next the user is giving a consent to enter a verification code after the successful sign in. By default two verification methods are offered. Users may opt into getting a verification code via email and to use an authenticator app.


The verification code delivery via email will rely on the email address associated with the user account. This is a less secure method than using an authenticator app since there may be other individuals who can read the user’s emails.

Choosing the more secure method of verification will present the user with the QR code that needs to be scanned in Google Authenticator, Microsoft Authenticator, or another similar app. The QR code includes the information about the secret associated with the user account, the name of the app, and the name of the user along with some additional configuration data.


Google Authenticator immediately begins showing the verification code after the scan of the QR code. The time code will change every 30 seconds. There is no need to write down the verification codes since they will not be usable in the future. Other authenticator apps have a similar user interface and may require fingerprint scan or face recognition to display the verification codes.




If the user is not able to scan the QR code then they may opt to enter the setup key manually directly in the authenticator app. 


Users may also indicate that they need help installing an authenticator app. Three apps are offered by default. Scanning of the QR code with the camera of the mobile device will direct the user to the corresponding app store. 


Users must press the Next button when their authenticator app is configured through the QR code scan or after the direct input of the setup key. 

The configuration screen will present the list of the one-time use backup codes The backup codes are also available for the other verification methods including email, text message, and call.


The backup codes are stored directly in the user account. Each backup code can be used one time only as an alternative to the verification code in the situations when the mobile device with the authenticator app is not available and there are no other means of getting a verification code. Button Save will create a file with the current set of backup codes. Button Generate will produce a new set of backup codes. It is recommended to print the backup codes and have them stored in the safe place.

Users complete the configuration by pressing the Enable button. This will result in the request to enter a verification code. Type in the verification code displayed in the authenticator app or get the code via email. Successful input of the verification code will enable the 2-factor authentication for the user account. The backup codes are not accepted during the setup verification. The objective of the setup verification is to ensure that the user is able to get the verification codes with the selected methods of delivery


Living With 2-Factor Authentication

The application will still require the user to enter the username and password in the custom or standard Login form.


Successful identification of the user will present the request to input the verification code. The user may opt to enter a one-time use backup code as an alternative to the verification code. Input of the incorrect verification or backup code will count as a failed login attempt. Multiple failed attempts to verify the username and password will result in the locked user account.


If the device can be trusted then the further requests to input the verification code can be suppressed by selecting the “Trust this device” option. The encrypted cookie with a unique verification code associated with the user name will be created. The application will verify the code stored in the cookie after the successful sign in to confirm the user identity.

Selection of the verification method may reveal the Get Verification Code button. The verification code is delivered when the button is pressed. 


The setup screen can be re-entered by choosing the same “2-Factor Authentication” option in the user context menu. Users will be greeted with the verification code input screen before the setup options are presented. Users may change the verification code delivery methods, download the backup codes, or generate a new set of backup codes. Changes will be saved after another successful verification code input.

Disabling 2-Factor Authentication

Users may disable the 2-factor authentication by withdrawing the consent to enter a verification code. The withdrawal of the consent in the setup screen will disable the 2FA for the user account when the Save button is pressed.


The multi-factor authentication can be permanently disabled in the application by setting the server.2FA.enabled option to false in the ~/app/touch-settings.json configuration file. 

Prerequisites

2FA requires the additional data to be stored in the user account in the application database. If you have enabled the standard membership feature in your Code On Time app, then there is no need to do anything else. The application will store the 2FA setup in the Comment field of the user membership account.

The screenshot below shows the Comment field of the admin user configured for multi-factor authentication. 


If the custom membership manager is configured for the Code On Time application, then make sure to map the Comment logical field to the corresponding column in your own “Users” table.

The application framework provides two methods in the ApplicationServices class to read and write the user authentication data. Developers may override the methods ReadUserAuthenticationData and WriteUserAuthenticationData to store the data elsewhere. 


Verification Code with SMS and Call

Developers may enable three additional methods of verification code delivery in the app. These include sms, call, and dial. Enter the following options in the touch-settings.json file of your application to enable these methods:


Re-enter the 2FA setup and enable the verification code delivery via text message and call. Save the setup.


Verification methods app and email are enabled by default and available on the 2FA setup screen.  Delivery via email will require specifying the SMTP server parameters in Settings | Features | Smtp Configuration section of the project configuration. 

There is no built-in support for sms or voice call delivery of the verification code in the framework. Developers may sign up for the text and voice delivery services from their favorite messaging provider and override two methods in the ApplicationServices partial class.

Method OtpVerificationData must provide the means of verification code delivery for the given username parameter. The implementation below uses the sample static values.

Method OptAuthenticationSendVerificationCode implements the physical delivery of the verification code. The implementation must send the contents of the message parameter to the contact using the code specific to the messaging provider.


Users will initiate the delivery by selecting the corresponding method and pressing the Get Verification Code button. The delivery confirmation message will be displayed at the bottom of the screen. The framework obfuscates the email addresses and phone numbers available in the list of methods.


The dial verification method entered in the server.2FA.verify.dial option in touch-settings.json file. It will provide the user with the phone number to call. Use this delivery method if the live operator will be available to the application users to assist with their identity verification. The operator may enter the one-time use backup code directly into the user account in the Membership Manager or in a custom form. This backup code may be a word or a number that the operator will communicate to the user after their identity is confirmed.

Trust No One 

Developers may force the users to always enter the verification code when signing into the app.

Parameter server.2FA.trustThisDevice must be set to 0 in touch-settings.json to hide the “Trust this device” option on the verification code input screen.

The default value of the parameter is 180. It specifies the number of days during which the user will be able to avoid entering the verification code when signing into the application after the initial verification with the “Trust this device” option. 

If the user has lost access to the “trusted” device then the 2-factor authentication must be disabled and enabled one more time on the user account to invalidate any previous trusts.

Verification Code Length and Period

The default length of the verification code is set to 6 digits that are changing every 30 seconds. Application framework will compare the provided verification code with the codes produced in the 180 second window. 

The length of the verification code, the period of change, and the testing window can be changed like this:


The longer testing window can be specified if the delivery of the verification codes is slower than 3 minutes.

Parameter server.2FA.code.window is provided exclusively for the application. It will generate multiple verification codes in the specified time window to find the match to the verification code provided by the user. 

Do not change the length and period if you expect the end users to work with the authenticator apps from Google or Microsoft. These apps will ignore the parameters and generate the 6 digit code every 30 seconds.

Salesforce Authenticator will respect the length and period parameters. It will correctly generate the 4-digit verification code every 60 seconds as instructed by the app.




Developers can specify their own set of the authenticator apps to be available on the setup screen. Option server.2FA.setup.authenticators is an array of name/url pairs in touch-settings.json. This custom set is presented to the user asking for help with the installation of the authenticator app. Users are prompted to scan the QR code with the device camera, which will present the link leading to the app store directly on the device.

Backup Codes

By default the 2FA setup will produce ten 8-digit backup codes. Developers may opt to configure their own set of backup codes.


This configuration will produce the set of five 3-digit backup codes.


Users must print or save the backup codes and use them if the access to the verification methods selected during the setup is lost.

Auto-Setup

By default the 2-factor authentication requires the users to opt in. Developers have an option to automatically generate the 2FA setup for the user accounts at the moment when the user is singing in.

For example, the following configuration in touch-settings.json will automatically create the 2FA setup with the email-based delivery of verification codes. 


Users will enter the username and password and press login. The framework will create the 2FA setup if it does not exist. Users will be immediately presented with the request to enter the verification code. The only option to get the verification code is the email. 



Make sure to set up the SMTP Configuration in the Settings | Features of the application. Otherwise users will not be able to access the application.

Applications may support the other methods of verification that can be configured in server.2FA.verify section of touch-settings.json as explained above. Users will need to enter the setup mode through the user context menu to change their verification preferences. 

If a user withdraws the consent to enter the verification code, then the application will perform the automatic setup during the next sign in to keep the user accounts protected.

Login Without Password

Automatic setup makes it possible to disable the requirement to enter the password during the setup. Set the server.2FA.disableLoginPassword to true and server.2FA.setup.mode to auto in touch-settings.json. Optionally specify the automatic setup methods. The default setup method of verification code delivery is email.


The built-in login form will not ask the user to enter the password.


The framework will locate the user account by name. If the user is found, then the automatic 2FA setup is performed when needed. The user will be asked to enter a verification code to sign in. 

The initial verification is done via email. Users may opt to enable the authenticator app verification in the setup. We recommend also setting the server.2FA.trustThisDevice option to 0 to ensure that the verification code is always requested.
Thursday, October 26, 2017PrintSubscribe
User Pictures in SharePoint, Facebook, Google

Release 8.6.7.0 introduces automatic capturing of user profile picture for Facebook, Google, and SharePoint accounts when configured for Single Sign-On with OAuth. The user picture is captured directly from the identity provide and stored in the CMS of the app.

We have corrected the latest iteration of themes to re-enable conditional styling rules. Just make sure to place your CSS rules into ~/css folder instead of ~/touch.

image

The release aslo corrects muscellaneous issues related to the introduction of the new file structure compatible with the upcoming native apps. See the details below.

  • Restored modal-never tag function to force fullscreen presentation even when modal forms are allowed by the screen size.
  • Summary in the sidebar does not display NULL values anymore.
  • Fixed. If Int field has Text values in Items then advanced search must be configured as text. Previously the lookups were displayed as simple “numeric” values.
  • Lookups with static context field values (e.g. "CategoryName='Condiments'" or "CategoryID=1, CategoryID=5") do not expose them in the filter that can be cleared. Also the specified fields are hidden in the filtered view. This reproduces the behavior of the Classic UI.
  • Static lookup fields with Context dependencies will first cause Calculate if defined and then popuplate the list of values. Previously items stopped being populated.
  • Actions in "Custom" group are rendered as "hidden" if defined in the view layout but not available in the controller in Touch UI apps.
  • Automatically created row of "Custom" actions is removed when there are no "visible" custom actions in Touch UI apps.
  • “Form Layout” feature in Developer Toolbar of Touch UI apps correctly pre-selects the current page size for the layouts available for download.
  • Calendar view style correctly displays tabs making possible interactive selection of Day/Week/Months/Year/Agenda mode.
  • Resolved the bug with “Controller not found.” when ~/controllers folder is spelled in camel notation.
  • SharePoint OAuth now downloads user profile photo if supported.
  • Fixed - Blob fields marked as "required" will allow submitting a form. Physical BLOB  columns in tables must allow NULL values for apps to allow uploading of large content. Developers can mark BLOB fields are required to force a submition when the record is created.
  • Facebook OAuth now supports download of profile picture.
  • Fixed issue with "Sync Roles" showing true in oauth wizard.
  • Google OAuth provider now downloads user avatar.
  • Fixed issues with Web App Factory publishing.
  • Files daf-resources.js and daf-resources.min.js are now removed from ~/js/sys folder, since these files are not needed for an application to execute correctly. Only the localized versions of these files will remain in the project.
  • Fixed issue where ASPX projects adding an account would navigate to "login" instead of "login.aspx".
  • Removed "Sign Up" and "Forgot Password" if Active Directory is enabled in Membership and Autentication Settings.
  • Included images & fonts in Web App Factory. Fixed regression when js folder does not exist.
  • Toolbar located at the bottom of the sidebar will become hidden if there are no icons displayed in it.
  • Model Builder - Duplicate model field names are not created when columns are borrowed from the master tables joined in the model query.
  • Ensured duplicate site content is not created if model exists with name "SiteContent".
  • Removed legacy rules app-icon-check to prevent interferance with the ui-btn::after in the grid/list/cards.
  • Ensured bootstrap CSS link in Classic projects is formed correctly.
  • Disabled Native App SUpport for ASPX projects.
  • Removed unused references to AJAX framework script resolution.
  • Fixed issue with OAuth registration - adding system identity no longer sets content type to "application/octet-stream".
  • Ensured that Active Directory authentication configuration will cause the login button to display.
  • Fixed issue with Web App VB not including culture JS files in assembly.
  • Fixed compilation issues of GetManifestFileServiceRequestHandler when implemented in Visual Basic.
  • Removes remaining references to Sandbox project created in WebApp Factory projects.
  • Fixed issue with Localizer JavaScript encoding values in controls.