|
1 | 1 | Authorization Service
|
2 | 2 | =============
|
| 3 | +## OAuth 2.0 |
3 | 4 |
|
4 |
| -### Running the application |
| 5 | +OAuth 2.0 is the industry-standard protocol for authorization. The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions (via a token) across a network of web-enabled applications and APIs. |
| 6 | +OAuth 2.0 is not an authentication protocol and is not primarily used to identify a user. Although it is essential to authenticate both the user and the client in any authorization flow defined by the protocol. |
| 7 | +There are number of grant types/methods for a client application to acquire an access token which can be used to authenticate a request to an API endpoint. |
| 8 | +The client authentication enforces the use of the API only by known clients. On contrary, the serialized access token once generated, is not bound to a specific client directly. |
| 9 | + |
| 10 | +## OAuth2 Roles |
| 11 | + |
| 12 | +* **Resource owner (the User)**: An entity capable of granting access to a protected resource. Also referred as an end-user. |
| 13 | +* **Resource server (the API server)**: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. |
| 14 | +* **Client**: An application making protected resource requests on behalf of the resource owner and with its authorization. |
| 15 | +* **Authorization server**: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. |
| 16 | + |
| 17 | +## Grant Types |
| 18 | + |
| 19 | +When a client application wants access to the resources of a resource owner hosted on a resource server, the client application must first obtain an authorization grant. OAuth2 provides [several authorization grants](https://alexbilbie.com/guide-to-oauth-2-grants/). Each grant type serves a different purpose and is used in a different way. Below are OAuth2 grant types: |
| 20 | + |
| 21 | +* **Authorization Code**: |
| 22 | + The client redirects the user to the authorization server with parameters, response_type as code, client_id, redirect_uri and scope. The authorization server validates the request and asks user to login. The user login into the authorization server and approves the client. Upon user's approval the client is redirected to the redirect URI with parameters, state and authorization code. The client then sends a POST request to the authorization server with parameters, grant_type as authorization_code, client_id, client_secret, redirect_uri and code with the authorization code from the query string. The authorization server responds with a JSON object containing token_type as Bearer, expires_in, access_token and refresh_token. |
| 23 | + |
| 24 | +* **Implicit**: |
| 25 | + The implicit grant is intended to be used for single page web apps which can’t keep client secret because all of the application code and storage is easily accessible. Here the authorization server returns an access token instead of an authorization code. The client redirects the user to the authorization server with parameters, response_type as token, client_id, redirect_uri and scope. The authorization server validates the request and asks user to login. The user login into the authorization server and approves the client. Upon user's approval the client is redirected to the redirect URI with parameters, containing token_type as Bearer, expires_in and access_token. It does not return a refresh token. |
| 26 | + |
| 27 | +* **Resource Owner Password Credentials**: |
| 28 | + It is mainly used by trusted first party clients. The client asks the user for their authorization credentials (username and password). The client then sends a POST request to authorization server with parameters, grant_type as password, client_id, client_secret, scope, username and password. The authorization server responds with a JSON object containing token_type as Bearer, expires_in, access_token and refresh_token. |
| 29 | + |
| 30 | +* **Client Credentials**: |
| 31 | + It is used for machine-to-machine authentication where no specific user's permission is required to access data. The client sends a POST request to the authorization server with parameters, grant_type as client_credentials, client_id, client_secret and scope. The authorization server responds with a JSON object containing token_type as Bearer, expires_in and access_token. |
| 32 | + |
| 33 | +* **Refresh token**: |
| 34 | + It is used to get a new access token after expiration of current access token. The client sends a POST request to the authorization server with parameters, grant_type as refresh_token, refresh_token, client_id, client_secret and scope. The authorization server will respond with a JSON object containing token_type as Bearer, expires_in, access_token and refresh_token. |
| 35 | + |
| 36 | +### Installation and Running of PostgreSQL Server |
| 37 | + |
| 38 | +* Download latest [Windows PostgreSQL Installer](https://www.postgresql.org/download/windows/) and follow windows installation steps. |
| 39 | +* Alternatively, can download [Windows PostgreSQL Binary Archive](https://www.enterprisedb.com/download-postgresql-binaries) and extract the zip file. POSTGRE_SQL_HOME is the path to the unzipped PostgreSQL **pgsql** directory. |
| 40 | +* Run the below [pg_ctl](https://www.postgresql.org/docs/9.5/static/app-pg-ctl.html) utility commands to register PostGreSQL as service in POSTGRE_SQL_HOME/pgsql/bin directory. |
| 41 | +* Create a new user named **appuser** and new database named **testdb** using below **psql** commands. The user and password are added to auth-service.yml configuration file as spring.datasource.username (and password). |
| 42 | +* PostGreSQL runs on default port 5432. |
| 43 | + |
| 44 | + |
| 45 | + createuser --password postgres |
| 46 | + pg_ctl.exe register -N postgres -U appuser -P secret -D "POSTGRE_SQL_HOME/pgsql/data" |
| 47 | + pg_ctl.exe register -N postgres -D "POSTGRE_SQL_HOME/pgsql/data" |
| 48 | + pg_ctl.exe -D "POSTGRE_SQL_HOME/pgsql/data" -l logfile start |
| 49 | + psql -U postgres |
| 50 | + psql -U appuser postgres |
| 51 | + create user root with password 'verysecret'; |
| 52 | + alter user root createdb; |
| 53 | + create database testdb; |
| 54 | + \c testdb; |
| 55 | + |
| 56 | +### Running the Authorization Service |
5 | 57 |
|
6 | 58 | Pass the new AUTH_SERVICE_PASSWORD, CONFIG_SERVICE_PASSWORD from the [config-service](/../config-service/README.md) to access auth-service.yml configuration file, corresponding passwords FINANCE_SERVICE_PASSWORD for finance-service and ANALYTICS_SERVICE_PASSWORD for analytics-service respectively.
|
7 | 59 |
|
@@ -125,3 +177,6 @@ Pass the new AUTH_SERVICE_PASSWORD, CONFIG_SERVICE_PASSWORD from the [config-ser
|
125 | 177 | }
|
126 | 178 | }
|
127 | 179 |
|
| 180 | +### Notes |
| 181 | + |
| 182 | +* Authorization service uses [MapStruct](http://mapstruct.org/) for mapping between domain object to DTO object. MapStruct requires [mapstruct-processor](https://github.com/mapstruct/mapstruct) to be configured in gradle to generate the corresponding Mapper implementation for defined MapStruct interface. Hence it is highly recommended to **run gradle build before running authorization-service** to avoid Spring NoSuchBeanDefinitionException for MapStruct autowirings. |
0 commit comments