## Authorization The authorization process verifies whether you have permission to access the data you want from the server. You may include parameters of authorization to access OData. OData2Poco provides authorization types that make it easy for you to handle authentication protocols. The supported authorizations are: - No Auth - Bearer Token - Basic auth - OAuth 2.0 - Windows NTLM authentication. - Microsoft Digest authentication. - Integrated Windows Authentication, enabling users to log in with their Windows credentials. *Note: OAuth2 is supported by o2pgen v3.1.0+* ### Bearer authentication A bearer token is a security token. Any user have a bearer token can use it to access data resources without using a cryptographic key. To use a bearer token: Use Authentication type `token` with the option `(-o token)`. Enter in the commandline the value of the token as a password parameter using the short/or long options: -p eyJhbGciOiJSUzI.. -o token #Or --password eyJhbGciOiJSUzI --outh token The library pass the token to the headerRequest of HttpClient ### Basic Auth Basic Auth is an authorization type that requires a verified username and password to access OData resource. To use Basic Auth: Enter the value of the username as and the password parameter: -u username -p password -o basic --user username --password mysecret --outh token ### OAuth 2.0 OAuth 2.0 is an authorization type that enables you to connect to OData service without exposing your password. OData2Poco uses the standard OAuth 2 two-legged authentication process, which proceeds as follows: Obtaining a token using two-legged authorization is done by Sending a call to the OAuth2 Token server by specifying your client credentials data, and the Token server will return access_token. The client credentials data are: ``` Client_id Client_secret grant_type: client_credentials ``` To use the OAuth 2.0 authorization: You have to pass the following parameters: - The client_id using the option `-u , --user` - The client_secret using the option `-p, --password` - The Token endpoind through the option `--token-endpoint` - The Token parameters through the option `--token-params`. The Token params are key/value pair parameters(without client_id, client_secret because they pass as described above). Each pair is in the form `key:value` and they are separated by '&' and may include resourse /scope/tenant/... resource=https://url/to/resource&option1=... For example: --token-params "resource=https://myorg.dynamics.com&audience=http:/my_app" OData2Poco connects to the token endpoint (Oauth2 server) and require access_token based on these parameters. The endpoint reply with access_token which is then paseed to the OData service. If you get an access_token (for example using postman), you can pass it as a password option and you need not to pass client_id,client_secret,Token endpoind and Token params ### Example1: using Oauth2 authentication: For OData service of 'Dynamics 365 for Finance and Operations' Use the following PowerShell script: **In PowerShell** ```powershell # Oauth2 example # Set the value of options $resource='https://abc-123456devaos.cloudax.dynamics.com' $url="$resource/v1.0" $tenant="e6gaaf8f-c0ef-4c1d-0052-a05006cc86b9" $client_id="710bad1c-1d5g-4ecc-8fac-34994f5002b0" $client_secret="MNOpq23LGZ6SP8fCGJrCnvqp2/EmlhFr11mVaQsMvL9" $token_endpoint="https://login.microsoftonline.com/$tenant/oauth2/token" set token-params="resource=$resource" # run the command O2Pgen.exe -r $url -o auth2 -u $client_id ` -p $client_secret ` --token-endpoint $token_endpoint ` --token-params $token-params #other options ``` **Note:** use the symbol backtick ` to concatenate the arguments. ### Example2: using Bearer authentication If you have the `access_token` or get it in postman tool, you can use it as a password option: **In PowerShell** ```powershell $token='aaa-bbb-cccee' $url='https://abc-123456devaos.cloudax.dynamics.com' o2pgen.exe -r $url -o token -p $token ``` ### Example3: using Basic authentication If you Access server using basic authentication with user and password : **In PowerShell** ```powershell $user='aaa-bbb-cccee' $password='secret' $url='https://abc-123456devaos.cloudax.dynamics.com' o2pgen -r $url -o basic -u user1 -p $password ``` ### Example4: Windows NTLM authentication ```powershell $url='https://abc-123456devaos.cloudax.dynamics.com' o2pgen.exe -r $url -o ntlm -u username -p password ` --domain your_domain ``` ### Example5: Microsoft Digest authentication Enter the Following parameters: -o digest -p token ### Example6: Integrated Windows Authentication If you are logged to the windows domain Active Directory, you can login without passing login parameters. By default ``` o2pgen.exe -r $url -o none #or without option -o o2pgen.exe -r $url ``` **Securing password** To avoid passing password in the commandLine argument, store it in Environment variable and use it instead: example ``` --password %PasswordVar% ``` in Windows ``` --password %PasswordVar% ``` in Linux/MacOs OS auto resolve these environment variables in the commandline and o2pgen read it. **Testing Environment:** O2pgen in OAuth2 is tested with the following service: - Dynamics 365 for Finance and Operations (thanks to @darinvanatta) - https://graph.microsoft.com - Dynamic 365 CRM - Google Oauth2 ---------------------------------- ## Allow setting of SSL-TLS protocols The option `--ssl', enable the specified TLS protocol when making HTTPS requests. Allowed Valid values are: Tls, Tls11, Tls12, Tls13. By default, all available protocols are enabled. Note that enabling older, less secure protocols like TLS 1.0 or TLS 1.1 may pose a security risk. Consult with your system administrator or IT department if you're not sure which protocol to use. ### Example Enables TLS 1.2 for HTTPS requests. ``` o2pgen.exe --ssl tls12 ``` ### Example Enables TLS 1.1 and TLS 1.2 for HTTPS requests. ``` o2pgen.exe --ssl tls11,tls12 ``` **Note:** Users may need to run the command prompt or terminal window with elevated privileges (i.e., "Run as administrator") in order to use the `--ssl` option, depending on the security settings of their system. *When this option is useful* Enabling specific TLS protocols can be useful in certain situations, such as: 1. Encountering compatibility issues: Some servers or clients may be configured to use older TLS protocols that are not compatible with newer protocols. In this case, you may need to enable an older TLS protocol, such as TLS 1.0 or TLS 1.1, in order to establish a connection. 2. Compliance with security policies: Some organizations may have strict security policies that require the use of specific TLS protocols. In this case, you may need to enable a specific TLS protocol in order to comply with these policies. 3. Performance optimization: In some cases, enabling specific TLS protocols can improve the performance of your application by reducing the overhead of the TLS handshake. For example, TLS 1.3 introduces a number of performance optimizations that can reduce the latency and improve the throughput of HTTPS requests. Note that enabling older, less secure TLS protocols like TLS 1.0 or TLS 1.1 should be done with caution, as it can make your application vulnerable to security threats. You should only enable these protocols if you have a specific need to do so, and you should consider upgrading your server or client software to support newer, more secure TLS protocols. ----- ## Allow to Skip Certification Check in http connection The help text: ``` -S, --skip-check Skips certificate validation checks that include all validations such as trusted root authority, expiration, ... . ``` Ignore SSL certificate errors when making HTTPS requests. This option can be useful for testing or when connecting to a server with a self-signed certificate. Use this option only when you're sure that you trust the server you're connecting to, and you understand the implications of ignoring SSL certificate errors. *When this option is useful:* - This option can be useful for testing or when connecting to a server with a self-signed certificate. - This option should not be used in production environments (except you trust the server) - If you're not sure whether you should use this option, consult with your system administrator or IT department. ------ ## Allow to specify Http header in Odata http connection with the computing of base64 The New option: `--http-header` or `-H` enable to pass http header to httpClient. Http Header as a list of key/value pair separated by ';' e.g. key1:value1;ky2:value2. #### Example This example show how to pass Bearer token for Authorization and extra headers. (Note that auth is none). ``` o2pgen --url http://localhost/odata --auth none ^ --http-header "Authorization=Bearer %token%";key1=123;key2=abc ``` Also, header can be entered using the repeating option like: On Windows: ``` -H "Authorization=Bearer %token%" ^ -H key1=123 ^ -H key2=abc ``` On Linux/Mac: ``` -H "Authorization=Bearer %token%" \ -H key1=123 \ -H key2=abc ``` ## See Also [Using Proxy Server](proxy)