远端用户拨入验证服务

用戶端-伺服器結構

RADIUS協定是一種基於主從式架構的協定。RADIUS協定中的用戶端是對用戶（人或者電腦）提供網路連接服務的器材，對伺服器提出驗證和計費要求。伺服器針對用戶端的通過進行驗證和計費給予應答。伺服器只有針對用戶端的請求進行應答，而無法反方向地對用戶進行服務停止等的請求。

RADIUS用戶端的實體

網際網路連接服務中，撥號呼叫裝置和寬頻接入伺服器（BAS、Broadband Access Server）等網路接入伺服器（NAS、Network Access Server）即為RADIUS用戶端。（雖然名字含有「伺服器」，但從RADIUS協定的角度來看是用戶端。）
無線LAN環境中的無線接取器和VLAN中的交換機等都是。
在內容提供的服務中，Web 伺服器起到RADIUS用戶端的作用。
在行動電話網路（例如LTE等）網路中，核心網節點作為RADIUS用戶端，使用RADIUS的認證和記帳功能。

協定的概要

RADIUS協定使用UDP協定承載。RADIUS協定自身不具備對談管理機制，UDP也缺乏相應機制，因此RADIUS的路徑管理和傳輸可靠性需要由使用RADIUS協定的應用程式來實現。
用戶端對伺服器提出「RADIUS請求包」，伺服器對用戶端傳送「RADIUS應答包」。
雙方的封包，頭部分由20個 8位元和「屬性」組成。頭部分包括類別碼（Code）1個8位元、辨識碼（Identifier）1個8位元、封包整體長度2個8位元、驗證碼（Authenticator）16個8位元。辨識碼根據用戶端決定的需求而設定，伺服器根據根據請求包的驗證碼生成應答包的驗證碼里，因為用戶端需要在收到的應答包與之前發出的請求包匹配。用戶端可以僅用累計數值編號來設定驗證碼，但驗證碼並不必然是序列號。驗證碼是為了證明無傳送者偽裝和篡改。屬性部分包含任意個屬性（AVP，Attribute Value Pair，字面上為屬性值對）。屬性採用TLV格式，即「類型-長度-值」格式。屬性値對由1個8位元的屬性編號、1個8位元的長度，以及屬性的値組成。値的類型可以是4個8位元的整數値、4個8位元的IP位址、1 - 253個8位元的文字串等。
對於每個屬性編號，每個屬性値對里值的含義在RFC檔案里均有規定，還可以通過給屬性編號賦予新的定義來增加使用目的，RADIUS協定的靈活性所在也是其最大的特徵。但是一般不推薦各個機器產商為各自目的獨自給屬性標號賦值。產商特有功能應做為屬性編號26號(Vendor Specific)的值與產商編號一起加到資料里。屬性編號 26 號的屬性値對一般稱為 VSA (Vendor Specific Attribute) 。廠家編號由IANA進行管理和賦予。
協定為了實現驗證和計費，規定了各種相應的屬性。為實現驗證，用戶名稱和密碼各有屬性編號。撥號上網使用PPP時針對PPP用的驗證協定PAP、CHAP、EAP均備有各自的屬性編號。為實現計費，有使用秒數、收發資料量等的屬性編號。
RADIUS分組的最大長度，在RADIUS驗證協定中是4096個8位元、RADIUS計費協定中是4095個8位元，這個差異據說並沒有特殊含義，而是 RFC 當初的錯字將錯就錯地沿用下來的緣故。

協定流程

一個常見的RADIUS認證、計費協定的流程如下。
+------+                         +--------------+     +------------------+     +------------------+
| 用户 |                         | RADIUS客户端 |     | RADIUS认证服务端 |     | RADIUS计费服务端 |
+--+---+                         +------+-------+     +--------+---------+     +---------+--------+
   | 用户发起连接请求并提供用户名、密码 |                      |                         |
   |----------------------------------->| 认证请求消息         |                         |
   |                                    |--------------------->|                         |
   |                                    | 认证接受/拒绝消息    |                         |
   | 通知用户认证结果                   |<---------------------|                         |
   |<-----------------------------------|                                                |
   |                                    |（若认证已被接受）                              |
   |                                    | 计费请求（开始）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 计费响应消息                                   |
   |                                    |<-----------------------------------------------|
   |                                    |                                                |
   |                            ................                                         |
   |                            . 用户使用服务 .                                         |
   |                            ................                                         |
   |                                    | （可选）                                       |
   |                                    | 计费请求（中间）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 计费响应消息                                   |            |
   |                                    |<-----------------------------------------------|
   | 用户请求断开连接                   |                                                |
   |----------------------------------->| 计费请求（结束）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 计费响应消息                                   |
   | 通知用户连接断开                   |<-----------------------------------------------|
   |<-----------------------------------|                                                |
   |                                    |                                                |

共用密碼

UDP與TCP不同，無法辨識偽裝送信者和資料篡改。因此僅靠通訊對方的IP位址是不足以信任通訊內容的。為了防止偽裝和篡改，RADIUS用戶端和伺服器之間共用一個叫「共用密碼」的金鑰字串，將封包的內容和共用密碼得到的摘要資訊配給驗證符號和屬性值。應該為每對 RADIUS用戶端和伺服器準備一個共用密碼。針對一個RADIUS伺服器只用一個密碼而與所有RADIUS用戶端都共用會造成安全上的重大隱患。另外，從安全的角度來說，共用密碼的內容若被第三方泄露也是一大問題。

代理

自身作為RADIUS伺服器，而把實際的驗證和計費處理委託其他RADIUS伺服器的情況即為「RADIUS代理伺服器」。也就是說本身既是RADIUS伺服器也是RADIUS用戶端，將需求「轉送」。
可以通過判斷用戶名稱的字串改變轉送位址。比如用戶名稱做成含有電子郵件位址「@」符號和域名的字串，根據不同的域名部分字串轉送到其他RADIUS伺服器上。這種技術廣泛被利用於 ISP（網際網路服務提供者）之間的漫遊服務等。上述例子中用於判斷轉送目的類似域名的部分通常被稱為 Realm。

AAA

RADIUS協定是一種AAA協定，但由於RADIUS協定本身建立於AAA模式之前，因此，RADIUS協定中並沒有區分「驗證」和「授權」，而是合為「驗證」處理， 因此RADIUS用戶端在實際操作中無法知道被拒絕的原因是由於密碼錯誤還是因為沒有權限。

IEEE 802.1X

IEEE 802.1X是乙太網路中一個控制可否使用區域網路的一個協定。通過使用IEEE 802.1X和RADIUS協定，可以對僅通過RADIUS伺服器驗證的用戶允許區域網路服務。當然，為此需要配備IEEE 802.1X以及RADIUS協定雙方能使用的無線存取點或VLAN開關。另外「802.1x」中的 X 一般為大寫，這是因為小寫x易被人誤解其像數學中  一樣可代表任意參數。
IEEE802.1X和RADIUS協定均沒有規定實際的驗證步驟。實際的驗證中通常使用 EAP-TLS、PEAP、EAP-TTLS 等 EAP上的驗證步驟進行。為實現 EAP 驗證的資料交換，用戶終端和存取點或開關之間的乙太網路使用 IEEE 802.1X，存取點或開關與RADIUS伺服器之間使用RADIUS協定進行中継。
EAP-TLS 對於基於TLS數位憑證進行相互驗證（為防止偽裝服務提供者）這一點雖然很重要，但數位憑證的管理和運用對於一般機構是一個很大的負擔。PEAP 和 EAP-TTLS 的驗證步驟是在建立以 TLS 加密的通訊線路後再進行密碼資訊的交換 。EAP-TLS 與 PEAP・EAP-TTLS 的對比可以參照比較是通過網頁瀏覽器的TLS中利用數位憑證進行相互驗證還是 SSL 上的密碼驗證。