Please enable JavaScript.

Coggle requires JavaScript to display documents.

OAuth2.0 (dobre praktyki (weryfikowanie domeny/IP z której przychodzi…

- - - - wykorzystywane są dwie aplikacje, jedna będąca klientem – client.local oraz authsrv.local pełniąca rolę serwera autoryzującego. Klient – profileeditor-client – wcześniej zarejestrowany w serwerze – ma za zadanie uzyskać od serwera autoryzację do wykonania operacji określonych poprzez przykładowe zakresy get_name i edit_name (pobranie danych personalnych oraz możliwość ich edycji). Takie założenia powodują, że klient musi wygenerować następujące zapytanie HTTP (np. wykonując przekierowanie w przeglądarce właściciela zasobu)
        
        GET /auth?response_type=code& scope=get_name%20edit_name& client_id=profileeditor-client& redirect_uri=https://client.local/callback Host: authsrv.local
        
        response_type – zmienna definiująca metodę pozyskiwania tokenu
        
        scope – zmienna zawierająca listę zakresów (ang. scope) definiujących uprawnienia, jakie mają zostać nadanie klientowi. Zgodnie z specyfikacją kolejne zakresy oddzielane są od siebie spacją, którą w adresie URL reprezentuje wartość %20.
        
        client_id – zmienna informująca o tym, jaki klient występuje z żądaniem uzyskania autoryzacji.
        
        redirect_uri – informacja o adresie, na jaki ma przesłać odpowiedź serwer.
        
        Przesłanie takiego zapytania informuje serwer autoryzacyjny authsrv.local, że klient o identyfikatorze profileeditor-client chce uzyskać możliwość pobrania podstawowych danych użytkownika (zakres get_name) oraz ich edycji (edit_name). Dodatkowo kod autoryzacyjny (authorization_code) ma zostać wysłany pod adres https://client.local/callback – parametr redirect_uri.
      - Kolejnym krokiem jest sprawdzenie, czy właściciel zasobu, w imieniu którego wykonywany jest cały ten proces, jest już uwierzytelniony w serwerze autoryzacji. Jeżeli tak nie jest, w przeglądarce wyświetlany jest tzw. consent screen
      - Jeśli użytkownik zgodzi się na delegowanie uprawnień, serwer autoryzacyjny wykona przekierowanie z powrotem do klienta, co wygeneruje następujące zapytanie HTTP. W adresie URL zostanie przesłany tzw. kod autoryzacyjny. Nie jest to jednak to samo co token.
        
        GET /callback?authorization_code=<wygenerowany authorization code> Host: client.local
      - W kolejnym kroku klient wykona bezpośrednie zapytanie do serwera autoryzacyjnego o treści
        
        POST /get_token Host: authsrv.local client_id=sekurak&client_secret=[removed]&grant_type=authorization_code&redirect_uri=http://client.local/callback&code=<wygenerowany authorization code>
      - W zapytaniu przesyłany jest otrzymany kod autoryzujący oraz identyfikator i sekret klienta pozwalający na jego identyfikację. Jeżeli wszystkie przesłane dane są poprawne, serwer autoryzujący powinien odpowiedzieć w sposób podobny do tego
        
        HTTP 200 OK Date: Mon, 10 Aug 2016 12:39:13 GMT Content-type: application/json { "access_token": "6fgg1147fA781bc3fE9Rr312", "token_type": "Bearer" }
      - Taka odpowiedź świadczy o tym, że serwer pomyślnie zweryfikował tożsamość klienta oraz wartość kodu autoryzującego. Od teraz klient może wykorzystywać pozyskany token do uzyskania dostępu do chronionego API
        
        GET /protected_resource Host: authsrv.local Authorization: Bearer 6fgg1147fA781bc3fE9Rr312
  - - - It is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible.
      - differences
        
        response_type=token
        
        Secondly instead of the authorization server returning an authorization code which is exchanged for an access token, the authorization server returns an access token in URL, after hash symbol.
    - - Metoda Implicit Grant sprawdza się, gdy klient jest aplikacją JavaScript uruchomioną w przeglądarce. Pierwszy krok – zapytanie wysyłane do serwera autoryzującego – wygląda bardzo podobnie do trybu Authorization Code. Główną różnicą jest inna wartość parametru response_type
        
        1.
        GET /auth?response_type=token& scope=get_name%20edit_name& client_id=profileeditor-client& redirect_uri=https://client.local/callback Host: authsrv.local
      - Serwer autoryzacyjny po odebraniu takiego zapytania zweryfikuje, czy użytkownik jest już uwierzytelniony. Jeżeli nie, poprosi o podanie danych uwierzytelniających, a następnie w zależności od potrzeby wyświetli consent screen.
      - Wymienione do tej pory elementy są identyczne, jak w przypadku trybu Authorization Code. Pierwsza różnica pojawia się w sposobie, w jaki serwer zwraca token. To, co charakterystyczne dla tej metody, to fakt, że token zostanie przesłany w adresie URL, ale nie jako parametr, a wartość po znaku hash. Jest to o tyle istotne, ponieważ to, co znajduje się po znaku hash, nie zostanie nigdy wysłane do serwera, na którym uruchomiona jest aplikacja.
        
        HTTP/1.1 302 Moved Temporarily Location: https://client.local/callback#access_token=afgg1147fA781bc3fE9Rr312&token_type=Bearer
      - Klient JavaScript uruchomiony w przeglądarce może bezpośrednio pobrać token z adresu URL i wykorzystać go do kolejnych zapytań
        
        GET /protected_resource HTTP/1.1 Host: authsrv.local Authorization: Bearer afgg1147fA781bc3fE9Rr312
  - - - token_type with the value Bearer expires_in with an integer representing the TTL of the access token access_token the access token itself refresh_token a refresh token that can be used to acquire a new access token when the original expires
    - - grant_type with the value password client_id with the the client’s ID client_secret with the client’s secret scope with a space-delimited list of requested scope permissions. username with the user’s username password with the user’s password
    - - POST /get_token Host: authsrv.local client_id=sekurak& client_secret=<sekret klienta>& grant_type=password& scope=get_name%20edit_name& username=admin& password=<hasło właściciela zasobu>
  - - - grant_type with the value refresh_token refresh_token with the refresh token client_id with the the client’s ID client_secret with the client’s secret scope with a space-delimited list of requested scope permissions. (This is optional; if not sent, the original scopes will be used, otherwise you can request a reduced set of scopes.)
    - - token_type with the value Bearer expires_in with an integer representing the TTL of the access token access_token the access token itself refresh_token a refresh token that can be used to acquire a new access token when the original expires
  - - - token_type with the value Bearer expires_in with an integer representing the TTL of the access token access_token the access token itself
    - - If you are authorizing a machine to access resources and you don’t require the permission of a user to access said resources you should implement the client credentials grant.
      - suitable for machine-to-machine authentication where a specific user’s permission to access data is not required.
    - - Jest on jeszcze bardziej uproszczony w stosunku do poprzednich trybów, ponieważ klient wysyła jedynie do serwera autoryzującego swój identyfikator i sekret
        
        POST /get_token Host: authsrv.local client_id=sekurak& client_secret=<sekret klienta>& grant_type=client_credentials& scope=get_name%20edit_name
      - Po odebraniu takiego zapytania serwer weryfikuje przesłane dane i jeżeli wszystko się zgadza – generuje token
        
        HTTP 200 OK Content-type: application/json { "access_token": "6fgg1147fA781bc3fE9Rr312", "token_type": "Bearer" }
- - - - Upon successful authentication of the client and validation of the authentication request, the Authorization Server will respond with a unique identifier auth_req_id and a lifetime expires_in for the transaction. The client stores the identifier for validating callbacks and when making token requests. When a client calls the token endpoint with an expired auth_req_id, the Authorization Server will return an error. Likewise, the client can omit identifiers that have expired, if no token or notification was delivered in time.
      - If the client is registered to use Poll (or Ping) mode, the Authorization Server may add an interval to its response. This interval specifies the minimum number of seconds a client must wait between two polling requests to the token endpoint. When omitted, the default value is 5 seconds.
    - - The CIBA specification supports signed authentication requests. All request parameters are encoded as claims of a signed JWT, with the parameter name as claim name and the values represented as JSON strings. No request parameters must be sent outside the JWT except for parameters needed for client authentication, such as client_id for mutual TLS authentication or client_assertion and client_assertion_type when using JWT assertions for client authentication. The signed JWT and the client authentication parameters are then added to the HTTP post request to the Backchannel Authentication Endpoint.
- - - - are opaque, they do not contain any meaningful content, besides being really just a long string, generated to be be unique
    - - contain valuable, meaningful attributes, which may have to be decoded.
- - - - Since the server trusts the PKI, clients can rotate their certificates without having to update the authorization server about the change as long as the name and issuing CA remain the same.
    - - If there is no PKI to trust, the client may register a single certificate with the authorization server. During authentication, the server checks if the client uses the same certificate for the TLS session as was configured or registered for that individual client. The server trusts the pinned certificate. The client's organization does not have to maintain any public key infrastructure and can simply use a self-signed certificate for authentication.
- - - - Cookies normally work on a single domain or subdomains and they are normally disabled by browser if they work cross-domain (3rd party cookies). It poses issues when APIs are served from a different domain to mobile and web devices.
      - As we want to expand our application to let our data be used across multiple mobile devices, we have to worry about cross-origin resource sharing (CORS). When using AJAX calls to grab resources from another domain (mobile to our API server), we could run into problems with forbidden requests.
      - Since sessions are stored in memory, this provides problems with scalability. As our cloud providers start replicating servers to handle application load, having vital information in session memory will limit our ability to scale.
  - - - There is no issue with cookies as the JWT is included in the request header.
      - There is no issue with scaling because token is stored on the client side.